ServiceDesk 4.5.22 Update 05/22/11

Do you know what TAT is? 

It's a nice acronym for turn-around-time.  It's the quantity of days between when you receive a job order and when you complete the job.  The shorter your average TAT, obviously, the better.  This is particularly true if you have one or more large clients that score you on TAT, and dispatch more jobs to you when your TAT is tiny. 

This new feature is about helping you trim your TAT to the very smallest possible size.  Rather than telling you more here, we'll simply suggest you read the micro-manual we also created to acquaint you with this feature.  There's a button on which you can click, for this micro-manual, from within the (Shift-F7) JobsPerusal form:

Or, you may click on this link.

I confess. 

The new feature (announced three releases back) that exposes within the DispatchMap when an "appointment" is connected to a ShopJob ended up being a little less than perfect.  I won't bore you with details explaining why, but the bottom line is that a number of users ended up with a number appointments in the DispatchMap claiming to be ShopJobs, when in fact they were not. 

That's fixed with this release. 

More importantly, there is also now better integration with SD-Mobile (also requires updates in SD-Mobile and SD-MobileLink).  It will now be very visible to the tech using Mobile if a particular appointment is setup as a ShopJob (no more mistakenly driving to the customer's location).  

Improved SB-DispatchLink, and Connected Improved Handling on N.E.W. Jobs:

In the SB-DispatchLink program, for a long time, we've been capturing a maximum of two phone numbers, and no email address.  It's all we could get, based on the fact ServiceBench's communication protocol did not provide more.  Or, rather, their old protocol did not.  A while back, however, they came out with a new protocol that added several fields not formerly available (among them, a third telephone number and email address).  We needed to re-program the SB-DispatchLink program to use this new protocol.  With SB-DispatchLink Ver. 4.5.0, that is done.  If the dispatch from ServiceBench has a third telephone number and/or email address (and assuming you've appropriately updated), those will now be plugged in for you. 

That's not all. 

In regard to work that comes from NEW (and if you're a servicer who does such work), we were formerly handicapped (with that old communication protocol) in regard to our ability to get some extra fields that are "kind-of" needed for NEW claims.  Owing to the absence of those fields, NEW claims have involved some extra work for users.  Yes, as core philosophy we hate extra work, and are very sorry you had to endure that. 

Anyway, the good news is that Ver. 4.5.0 of SB-DispatchLink (using that new communication protocol) is now able to grab the extra fields as needed for NEW claims.  It puts these in the ExtraNotes section of the Callsheet it creates.  They get transferred from there to the JobRecord when you make one, and when ServiceDesk fills-in the on-screen NARDA for you (preparatory to transmitting a claim), they'll be placed into its needed boxes, such that when you transmit, everything needed should go appropriately to its needed place, just as with claims to OEMs. 

In other words (if you did not get the above), there is now no need for you to separately obtain NEW's AuthoNumber, or to re-arrange how any of the NEW-specific fields are setup for you.  In fact, it's important that you do not re-arrange them.  Leave them just as inserted by the SB-DispatchLink program.  Based on that precise arrangement, ServiceDesk's insertion to the on-screen NARDA will be just as it needs to be (in regard to those particular elements, at least) for a successful claim. 

If you're a SB-DispatchLink user, please assure you update to 4.5.0 (or newer if present when you get there).  Dispatches as received via pre-4.5.0 versions will not grab the extra data, as needed for fully-automated NEW claims. 

If you're interested in how the specific "mapping" works, it's like this:

1.    SBDL places NEW's CRM/SR # and its Authorization # (embedded within what is esentially narrative text) into the ExtraNotes section of the underlying Callsheet (from whence, of course, it gets transferred to the JobRecord). 

2.    When SD auto-fills the on-screen NARDA from such a job, it extracts those two numbers (i.e., from the underlying ExtraNotes, and inserts, respectively, into the NARDA's Contract/Service Agreement Number and Special Authorization # fields. 

3.    Those boxes, in turn (and upon transmitting a claim), insert into SB's Service Agreement Number andAuthorization Number fields

4.    At the SB end, those two claims-transmission pockets get translated as needed right back into NEW.