ServiceDesk 4.4.45 Update 01/03/10

Effective on this date, LG has ended its former "CLS" integration system (which provided direct integration, between servicers and themselves, on both dispatch processes and claims) -- in favor of a new system called "GSFS."  It's our understanding they have also ended integration via ServiceBench.  Most alarmingly, their new system has no "handles" to facilitate the direct integrations (for dispatch processes and direct claims transmission) that were formerly enjoyed.  In fact, all that is available now, for integration (at least as we understand it), is the ability for you to upload claims via the old-fashioned file/batch-upload method -- though as connected to the new GSFS system (i.e., SD puts the claim information into a file, and you have to separately upload it via login to the GSFS website).

We don't know anyone that's happy with this, but (and at the least) here at Rossware we've provided you with a "just-in-time" update to facilitate claims creation in LG's new format.  Assuming you make your first GSFS claims on the morning of Monday the 4th, we believe it will work.  Our output has been tested with LG, and verified to be in the correct format. 

So long as I was busy creating a new claim submission format for LG, I figured I might as well tackle another item on my long, long, long list of projects -- which was to create a submission format for Samsung (in case it's not obvious to you, every claim processing entity has its own format into which claim data must be forced; each format is unique, and it requires a lot of program coding to make the data conform perfectly to each). 

In regard to this newly-added format for Samsung, I'm considerably less certain you'll enjoy immediate claim-submission success.  Samsung's documentation (detailing what's expected for their format) is very sparse in regard to a number of the needed fields -- leaving considerable ambiguity in terms of what must placed where.  I suspect further finessing will be required before we reach total success.  This finessing will likely depend on feedback from you (we've had no direct testing with Samsung, such as we have indeed had with LG).  I encourage you to use the on-screen NARDA's "Translation Tips" to see how, specifically, we are presently translating boxes from the NARDA into Samsung's claim format.  Again, I'll look forward to your feedback. 

Evolution is not always the best designer.  Way back in the early days of the DispatchMap, we realized it would be good to have a "Check-Off" there -- to visually indicate, in respect to an appointment, if it had been dispatched to the tech (i.e., actually given to him, so it was known that he had it).  We used an actual check-mark symbol for this purpose, and a simple Shift/Click action as the means for toggling an appointment to show it with check-mark, or not. 

That was terrific, except we soon realized it would be nice to have a somewhat similar (but different) action and symbol to indicate the tech had actually arrived at an appointment, and another to indicate he'd finished there.  So, we made added key/mouse-click combinations for these purposes (Ctrl/Click and Alt/Click), along with added associated symbols. 

That wasn't too bad: three different (and simple) key/mouse-click combinations, and three different associated symbols.  But if it's good to have indicators for those statuses, isn't it better to have indicators for more? 

What about showing, for example, if an appointment's PVR was done.  Hmmm.  That means another symbol (or symbols), and another key/mouse-click combination to toggle.  Now, with the simple key/mouse-click combinations already used, we had to resort to a more complex combination.  We chose Ctrl-Alt/Click. 

Still, a good concept can't quit growing.  Before long, someone suggested it would be good to have a check-off action to show a customer had been contacted (typically the evening prior) to confirm their expectation of the next day's appointment.  So, we added a "Confirmed-With-Customer" check-off (Shift-Ctrl/Click).  Then, as people began using that, they realized it would be good to have a different check-off to indicate confirmation had been sought (i.e.,. voice message left by telephone, email request sent, CyberOffice processes initiated, etc.).  We used Shift-Alt/Click. 

Finally, someone suggested it would be good to check-off to indicate the tech had arrived on a job, only to face a "No-Show" by the customer (Shift-Ctrl-Alt/Click). 

As you may gather, it reached the point where we'd used all the potential key/mouse-click combinations (see illustration of old DispatchMap Cheat-Sheet, about a page-down below), and if a user was interested in doing any of the check-offs manually (in truth, the need for this was typically limited by the fact many check-offs occur via automated means), it was a confusing combination of key/mouse-click combinations to remember.  There was of course an always-on-hand, easy-to-instantly access cheat-sheet to remind, but still, the inelegance of all those combinations was undeniable. 

And, wouldn't you know it, people eventually wanted still more check-offs. 

In particular, many companies have a person who advance screens each appointment, seeking to predict if particular parts are likely to be needed (intending to send the tech out with such parts, if so).  Some such companies asked for a check-off to indicate when such "pre-screening" had been performed. 

Many other companies do what might be called "post-screening."  That is, periodically throughout each day, someone in the office scans the DispatchMap looking for jobs on which the PVR has been done, but on which the job is not yet complete (i.e., those showing with a circle-X symbol).  That person opens the JobRecord, and immediately orders the parts -- which, presumably, the technician requested.  This is a rather brilliant practice, because it shortens completion times, and impresses the heck out of your customers.  Anyhow, these companies asked for a "this-job-has-been-post-screened" check-off. 

As noted, we'd already used all possible key-modifier combinations (as potentially combined with a left mouse-click; right mouse-clicks are used for other things) -- so there was a clear need to change our methods -- if we were going to accommodate such added check-offs. 

What I've done is to eliminate all items in that former zoo of key/mouse-click combinations -- except the initial and original one: the simple Shift/Click.  Now, when you want to toggle any check-off status on any appointment (in all cases, we're referring to its list  reference under the tech to whom it's assigned), do a simple Shift/Click.  In result, the system will display a list of all possible check-offs, and you simply must do one more click to pick the one wanted. 

Please note that any appointment's existing check-off status will show in the list with a line through it.  If you want to un-toggle that check-off (i.e, put the appointment back into a check-off status of nothing), click on the lined-through listing. 

Besides the fact you can now use those two new check-off statuses, there is obviously much added simplicity.  The DispatchMap's contextual Cheat-Sheet (right-click in any empty space to bring it up) reflects this.

Old DispatchMap Cheat-SheetNew DispatchMap Cheat-Sheet

In our view, a shorter Cheat-Sheet (that nevertheless accommodates more functions) is an improvement indeed. 

Please note, if you're using SD-Mobile, it's important with this update to also update SD-MobileLink to Ver 1.3.33 or above.  Prior versions will not know what to make of the new check-off statuses.