ServiceDesk 4.7.83 Update 05/12/14

Edited

Pre-Screening Jobs: Improved Mode of Review and Check-Off

It's not the same world it once was -- at least so far as concerns appliance service (apologies are repeated here, for those of you who work in other industries, for the fact our focus predominates on appliance service).  It used to be you could stock just a few hundred parts on a truck, and it was sufficient to produce a high rate of first-time completions.  Not any more.  Because manufacturers now use so many specialized operative parts, the only way to get a good first-time-completion rate is by advance-examining each job -- before the tech goes out -- and seeking on such basis to advance supply him with such parts as the symptoms suggest he may likely need.  Most service companies refer to this as "pre-screening."  Borrowing from the medical field, a few others refer to the process as "triage."

It was way back in '05 when we were first asked to add programming elements into ServiceDesk to specifically accommodate triage.  It should be noted, in this regard, any need for special treatment of actual parts, as involved in triage, relates solely to transfers from inventory (i.e., pulling items from a storeroom shelf, for the tech to take with him), as opposed to special-order parts.  For the latter (i.e., where you choose to special-order a part without first having a tech's on-site diagnosis proving need), the standard ordering mechanisms work just as perfectly as otherwise.  For pulling items from inventory, on the other hand (and specifically as connected with triage), standard mechanisms do not work so well.  There are a few reasons:

  1. Unlike special-order items, inventory items are not normally (i.e., absent some special system otherwise) tagged to a job.  Thus, absent some new and added mechanism, there was no way to know on the day of an appointment that the tech needed to be taking a pre-screened-for-the-job inventory item with him.

  2. Though the inventory system could nevertheless be used to simply transfer a pre-screened item from office to the tech (i.e., so he'd then have it with him when going), there was formerly no system to flag, if the tech ended up not using the part, that it now needed to be retrieved back from him. 

  3. Even the above assumes you can reliably predict which tech will be fulfilling an appointment.  This is often not true, and even if you have fairly definite plans, they can change (say the intended tech gets sick).  This makes any advance transfer, of a pre-screened-I-think-it-might-be needed part, problematic regardless.

  4. Another factor is you might end up needing a pre-transferred part elsewhere (e.g., for an across-the-counter sale).  It would make better sense to have it still in the office and available for such immediate use, as opposed to sitting in a tech's inventory waiting the day of an appointment on which it might be used.

Based on these factors, we created what we affectionately call "Speculative Parts Tagging" (a sub-part of which has sometimes been referred to as the "Anticipatory Parts Transfer").  The system was primitive at first, but has been augmented many times since, so that today it is reasonably robust.

At least, in and of itself, it has been pretty good.  Where it has lacked is regarding the larger environment in which it lives.  Specifically, we have not had any very good mechanism to facilitate having a particular person in the office know which jobs are due for pre-screening (i.e., just providing a simple on-screen venue in which to easily iterate through those particular jobs), and to readily distinguish those from ones that have been pre-screened.  It's a need that exists, indeed, whether your pre-screening results in spec-tagging from inventory, or special-ordering items that were not prior in inventory.  Either way, a good context of selective review makes excellent sense.  In its absence, folks have improvised with existing tools, though none have been been perfect for the purpose. 

We have had sort of a tool (a poor one, but a tool nonetheless).  Introduced in 2010, this mechanism involved a then-new check-off symbol in the DispatchMap (where every appointment always has some particular check-off status).  To indicate any particular appointment has been pre-screened, we made it so you can there toggle its check-off status to the CR symbol, as illustrated here:

For at least some, this provision allowed the DispatchMap's roster of jobs to function as a workable pre-screening (let-me-see-the-jobs-that-need-it, and distinguish-from-those-that-do-not) venue.  For most users, however, it has not been ideal.   As but one of its shortcomings, it's really a job that needs to be pre-screened, as opposed to the appointment for a job.  There are many others, but I'll not review them further except to say: I have described this old triage environment for the sake of providing context for introducing what's new.  In a nutshell, the tool as just described was formerly the only purpose-provided tool we had for this need.  Now, we have created something far better. 

As mentioned, it is much more a job that needs pre-screened, rather any particular appointment for a job.  Hence, the ServiceDesk JobRecord form (F7) now has a new control.  In default mode, you'll see it looks like this:

If you click on it, you'll get a dialog like this:

If you answer "Yes," the new control will change to look something like this (with particulars as apt, of course, to the circumstance):

There will also be a notation, automatically added to the JobRecord's narrative history, similar to this:

Thus, each JobRecord can now readily show on its face whether it's been pre-screened (and, even more, by whom and when).  And, it's permanently in the history.  This latter is important because, if need should arise, you can also toggle a job back out of pre-screened status (via method, dialog and results similar to as above-described, though opposite in effect):

To clarify, this method is intended to supersede use of the CR-symbol-check-off within the DispatchMap (at least as a mode for providing an optimized venue for conducting the pre-screening process).  Even so, we have not removed those symbols from relevance in the DispatchMap.  In particular, when you make an appointment for any job, its check-off status will automatically be set equal to whatever is the pre-screened status of the underlying job.  Additionally, when you change the pre-screened status of a job, the system will reach out, find any pending appointments as belong to that job, and change their check-off statuses to match (assuming they have not advanced to any check-off stage beyond the CR symbol, in which case they'll be left unaltered).  The general purpose is so you will continue to have pre-screen check-off visibility within the DispatchMap, though the real venue of operation has moved from there into, more specifically, the JobRecord environment. 

So, all this is pretty good, even excellent -- except something more is needed.

What is that something more?

Very simply, you need a convenient and powerful venue from which to review solely those JobRecords that have not yet been pre-screened.  You need this, to accommodate the process of doing the pre-screening on those particular jobs.  In other words, you need an optimized triage venue

With one added enhancement, our wonderful JobsPerusal form (Shift-F7) now fits this bill perfectly. 

Formerly, the bottom-right corner of the JobsPerusal form had these exclusion options:

Now, there is a new one, as shown here:

So, there it is.  All your pre-screen person must do is go to the JobsPerusal form (again, Shift-F7), pick any other inclusion-or-exclusion filters in which he or she is interested, then "check" this new filter option.  He will then be shown solely those jobs on which the pre-screen process is still pending (assuming, of course, he has prior checked-off all that have prior been pre-screened).  As he then goes through each such item in what is effectively a "needing-pre-screen" queue, and does the needed work, he'll check-off each item, and thereby gradually reduce the queue to none (and it will remain as none, of course, until others in the office add new jobs into it). 

Honestly, we think it's pretty ideal.  We think you're going to love it.