ServiceDesk 4.8.40 Update 11/17/17

It's been a couple of years since we first introduced SMS-based text-messaging as an alternate form of communication between you and your customers.  Naturally, we keep expanding the options for its use and effectiveness.  Regardless, there is one element of limitation that has until now persisted on the ServiceDesk side of SMS use.  It is that, if your SMS recipient chooses to reply, we have had no mechanism by which to assure the reply goes specifically back to the office person who sent out the initiating text (instead, it's gone as an SD-Mail to the person that is designated within SD-CyberLink as general recipient for SD-Mails). 

By way of comparison, this limitation has not existed in SD-Mobile.  In particular, if the tech uses SMS as the method for a "call-ahead," and if the recipient replies, that reply has appropriately gone right back (as, obviously, it should) to the sending tech. 

Now, the same "how-it-really-should-be" functionality works in ServiceDesk as well.  It will be the actual sender who receives, as an SD-Mail, any text-reply from a SMS-text recipient.  This should enable practices within ServiceDesk that are much closer to real-time, person-to-person texting (only with the office-side person working from within ServiceDesk, of course, as opposed to from a smartphone). 

It's important to know, BTW, success in this improvement depends on updating both ServiceDesk (to this version or above) and SD-CyberLink (to Ver. 4.5.55 or above). 

Improved Function and Definition for Initiating Auto-Dialing, SMS-Texting, Plain-Emails and/or User-Defined-Template-Based Emails and Texts:

While working on the above, we discovered that, as various features have over time been added in regard to what can be done via a telephone number and/or email address as present in a ServiceDesk Callsheet or JobRecord, we'd somewhat "mucked up" the set of keyboard and mouse actions that are available, and their results.  In other words, there was not very good across-the-board consistency, agreement and uniformity.  We decided a wholesale  alignment of functionality was needed, and have now accomplished that. 

In fact, we have created a new section in the Callsheet "Cheat-Sheet" to specifically describe each such potential action (in particular, as presently aligned for perfect and reliable consistency in every applicable context).  If you do not recall what a Cheat-Sheet is, it's a listing of otherwise-hidden actions that you can do in a particular operating context.  In each applicable context, you may display its Cheat-Sheet by doing a simple right-click on any point of the applicable form that is not otherwise functional.  

Thus, if you right-click in any portion of a Callsheet that is not otherwise functional, you'll see the Cheat-Sheet that's applicable to Callsheets.  In particular, you'll see it now includes a new section that looks like this:

Please note the second item among those above-highlighted -- in particular, the action to initiate a SMS text-message via a clicked-upon telephone number.  Though that function is not new with this release, the present method is now different, as compared to what was prior specified.  The reason is because, on doing this re-alignment, we discovered we'd inadvertently commandeered the same method (Ctrl/Rt-Click) -- as had formerly been specified for this action -- for the newer "Send template-based email or SMS" function (which you'll see as the item just below it, above).  Obviously, you can't have the same method triggering different functions, so we had to move one of the functions to a new method.  Thus, the "Send-SMS" function has been moved from Ctrl/Rt-Click to Shift/Rt-Click. 

 Please also note there is now clear differentiation between such action as is needed to initiate an email to each of multiple email addresses (as might be present in an email box), versus targeting a single email address.  The general notion is you should be able to instantly and effortlessly (even intuitively, once you are in habit of using these methods) initiate any of these communicative methods via any particular telephone number or email address target, as already present in either a Callsheet or JobRecord. 

Yes, the same actions will work precisely the same from either a current or archived JobRecord.  Regardless, the above-shown Cheat-Sheet reminders are found exclusively in the Callsheet Cheat-Sheet (in fact, the two JobRecord forms do not have their own Cheat-Sheet).  

Dedicated Handbook to Guide Customization of Automated and Semi-Automated Communication Scripts:

As contrasted from the above methods (which involve initiating otherwise non-automated communications), Rossware systems offer a great variety of communications that are either fully or semi-automated.  These may be initiated by ServiceDesk itself, SD-CyberOffice or SD-Mobile, and may proceed from either your office or, in the case of Tech "Call-Aheads," from technicians' mobile platforms.  Likewise, they may (depending on circumstances) be via email, RoboCall or text-messaging. 

For each context of such automated communication, we have made what you might call "canned" scripts.  In a nutshell, we have composed default language that we believe is generally optimized for best effectiveness.  Regardless, users have often wanted to substitute with their own text.  For such reason, we have built mechanisms, for customization of such scripts, in many places.  Just recently, we added facility by which you may customize the "Call-Ahead" scripts that are used from within SD-Mobile.  Naturally, we needed to provide instruction on how to do this new customization.  Until now, virtually all our script-customization instructions had resided in the SD-CyberOffice Handbook.  Initially this had made perfect sense, since it was initially SD-CyberOffice functions where such customization options were added.  Regardless, as we'd later added some customization options for some emails that are sent by SD-MobileLink, we'd tucked those instructions into there as well (not a perfect fit, but it kept related-subject-matter instructions together).  With need now to add even more instructions that are not related to SD-CyberOffice, we decided all our script-customization instructions needed their own dedicated home.  Accordingly, such instructions as were formerly in the SD-CyberOffice handbook have all been removed, combined with the needed new instructions, with all now established as its own handbook on the dedicated topic of customizing scripts.  At appropriate points, both the SD-CyberOffice Handbook and SD-Mobile Handbook now have hyperlinks to this separate document.  Here is your hyperlink, likewise, by which you can access from here.  

As an otherwise un-announced improvement, we recently made it so that, post-editing, Callsheet and JobRecord telephone number boxes positively enforce standard telephone-number format (e.g., either XXX-XXXX or XXX-XXX-XXXX).  Thus, if the text that you've placed into such a box was not in such standard format, but can be appropriately re-formatted, upon completion of any edit it will be.  For some users, this has created an issue.  It's because until now, they've been using a different-than-standard format (e.g., XXX.XXX.XXXX or XXX XXX XXXX).  The reason it's an issue is because, with the system now enforcing the standard format, they end up with a portion of their data in standard and a portion not.

Another matter that sometimes arises is, back in the day, some service companies would not bother with inclusion of the area code where the applicable code was the same as their own.  However, as telephone  numbers have proliferated, it has become increasingly intolerable to assume any particular area code, so all-cases inclusion of the area code is now much more typically the practice.  But, what do you do about all the older items in you data, in which the area code was omitted? 

This new feature is designed to address both issues.  The path to its access is deliberately obscure (it's not something you'll likely need to access more than once).  Basically, from the archived JobRecord interface, press Shift/Ctrl/Alt/Right-Click.  Then, just follow the dialog.  It's self-explanatory from there. 

BTW, the fact of having different formatting in telephone numbers now, as compared to older items in the data, is primarily cosmetic.  A particular client thought it was much worse than that.  In particular, they'd been using the dot-separator versus hyphen-separator format.  So now they thought, with some telephone numbers in one format and some in the other, the only path by which to exhaustively do an as-you-type database search was to type once in the dot-separator format and again in the hyphen-separator format. 

That is not actually true. 

In fact, when typing in a telephone number in any of the as-you-type database search contexts, it's best to type the number with no separating characters at all.  When you do this, the system finds any and all telephone number matches, regardless of format they are in.