ServiceDesk 4.7.26 Update 03/15/13

Several people recently asked for this.  They explained how, whether based on emails, robo-calls or a combination, ServiceDesk's afternoon send-outs of appointment-reminders for the next day (these include requests for the customer to confirm) have become so very valuable -- with one downside.  It is sometimes they forget to initiate the process, with big loss in benefit. 

What was requested, essentially, is a reminder, within ServiceDesk, providing a "kick," more or less, urging an operator to initiate the process. 

For context, we have not believed it is optimum for initiation of the send-outs to be entirely automated (i.e., set to automatically occur at a certain time each day, without user involvement).  It's because these reminder/requests should not go out until such point in the day when you have the next day's appointments rather fully worked out.  The time at which this is accomplished can vary.  Thus (and as a matter of design), we've thought it made most sense that it's regular practice, each afternoon, that someone is responsible for finalizing the next-day's roster (at least so much as is possible), then that person initiates the reminder/request send-outs.  

But, if users forget to do this, it's a problem.  This release presents our solution. 

Our first task, in creating this solution, was to create an interface where you can indicate how you want your alarm/reminder system setup.  Turns out we already had an interface for setting other appointment-confirmation preferences.  It was introduced a bit more than a year ago (see notes accompanying Rel 4.5.58), and was accessed via selection from within the DispatchMap's Cheat-Sheet:

While we could have made a new settings interface for our new purpose, it seemed sensible to keep all such related settings together, but with an important change.  You may notice the above explicitly notes its settings are "local" (i.e., particular to the station where set).  There had been no reason for this aside from ease in programming.  The new settings definitely needed to be system-wide.  For this reason, we have superseded the above with a new interface.  It incorporates the same three settings-options as were above available (while making them system-wide rather than merely local), and adds a much larger section for our new matter of concern.  This new interface is accessed from the Settings form (Ctrl-F1), via button as shown here:

Here (with moderate annotation), is what the new interface looks like:

Please notice the old three settings preferences are on the left (all that's truly new is on the right). 

As you can see, the interface allows you to setup successive reminders for up to three different persons.  Part of our logic is the first person might happen to be out of the office (or maybe sleeping) on a given day.  If so, the second person provides a backup.  Ditto between the second and third persons. 

As you can also see, there is provision for even further backup.  You can set it so, if no human responds at all to alarms as potentially setup for them (by, of course, manually initiating the reminder/confirmation-request send-out), the system will indeed go ahead, and automatically initiate the send-out, entirely on its own (this is the setup that's done in that bottom area). 

We suspect some users will be tempted to forego human reminders, with choice to depend entirely on automated send-outs.  We'd be reluctant to take this choice, for a couple of reasons.  One is it's likely optimum to initiate send-outs just as early as you are confident tomorrow's schedule is reasonably finalized.  If you're at that point earlier in an afternoon, it is beneficial to do it at that earlier-in-the-afternoon point.  At the same time, if you're not yet reasonably finalized, it's better to wait until you are.  A trigger that's wholly timed and automated cannot produce this flexibility. 

We suspect others may choose to depend entirely on the human reminders, leaving the machine-initiates option un-set.  We'd be more sympathetic with this choice.  However, if the machine-initiates option is set for a significantly-late time (at or after office closing hours), we believe it is arguable that it's better to have the reminder/requests go out even if automated (i.e., as opposed to not going out at all. 

If it is not clear from the interface, by the way, no alarms will sound for anyone if, by the time set for that alarm (or for the computer itself to initiate a send-out, if so set), a send-out has already occurred.  Thus (and to make it more clear), if person A responds by initiating the send-out, persons B and C will not be alarmed; nor will there be any automated initiation. 

The actual alarm/reminder is via a box that will appear on an applicable user's screen (dings several times as it initiates), and looks like this:

This alarm will appear on the designated desk for one minute, then extinguish for one minute, then re-appear and repeat the cycle.  The cycle will continue until either the send-out process initiates, or the day ends.  It will not stop simply because a second or third person's alarm period arrives (though if a second or third person initiates the send-out, that will indeed stop it).  If you are wondering, you can set as many or few, among the available alarms, as you wish. 

You'll notice there is also a section where you can designate the particular days of the week in which the alarm-potential will be operative.  There is a secondary effect in days selected.  Suppose you have days set as per the default/example.  You also have the computer-initiate option set to go, and on Friday no user initiates, leaving SD to initiate itself.  After initiating send-outs as applicable to Saturday's roster (which may or may not be empty), SD notices Saturday is not checked for applicability of this new assure-send-out feature.  Based on this, it figures it better initiate for Sunday as well, and so does so (likely no appointments for Sunday, so that may have little effect).  It then notices Sunday likewise is not checked for applicability, and so self-initiates the the next day's roster, which of course is Monday's.  Thus we achieve the logically-desired consequence that an auto-send as managed on Friday will actually send for appointments as scheduled for Saturday, Sunday and Monday (assuming days setup as in the example; you could setup otherwise if desired). 

Please note the old settings preferences (those that prior-existed, and have been moved to the left-hand side of this new venue) will need to be reset here, if you desire other than the default settings. 

We hope you enjoy this new enhancement, and make it profitable.