Managing automated customer communications

Our CyberOffice suite of functions is largely documented in a main CyberOffice Manual (see here). However, certain aspects of CyberOffice warrant their own separate treatment. We deal with one such aspect here. It involves elements of automation in customer communication whose setups are done within a particular Settings interface. To some extent, therefore, this document is about how to use that particular interface.

However, it is also about more. It is about how to directly use two rather major areas of functionality that are largely (or even entirely) setup for within this interface, and which either partially or totally involve complete automation.

The purpose in automation is for machines to do work, so humans don't have to. We believe automation is a very good thing.

ServiceDesk will happily create communications to your customers in any of three modes:

• SMS text messages ("SMS" stands for short-messaging-service; it's what we all do in our smartphones everyday)

• Emails

• RoboCalls

The problem is, to send any such communication, ServiceDesk must know which telephone number in a JobRecord is suitable for sending a text message to, or for sending a RoboCall to. Likewise, there may be multiple emails in JobRecord's email box. If asked to send an email, ServiceDesk must know if it should send to all in the box, or to only a particular one, etc.

We've created a structure that allows you to pick from among a few different strategies for designating, within a JobRecord, what are the intended communication targets for these purposes.

To access that structure, go to your Settings form (Ctrl-F1), and click as here shown:

That opens the interface that is at center of discussion for this document. For the present topic, we'll presently focus on this section within it:

This is where you'll specify what is the scheme you want to use, in your JobRecords, to guide ServiceDesk in knowing which telephone number(s) may be used for text messaging (if any), and which for RoboCalling (if any). Likewise, you'll specify the scheme that tells ServiceDesk which email address(es) maybe used for emailing (if any).

You may notice there are two main sub-sections. The first (in GREEN) is where you tell ServiceDesk what scheme to use in regard to any such contents as are found in the three telephone number boxes in a JobRecord (and as applicable, naturally, to whatever section is setup as the go-to party). The second is where you tell ServiceDesk what scheme to use in regard to whatever such textual strings as you've placed in the go-to party's email box:

In regard the GREEN section (which governs telephone-number-box treatment), our long-ago and original strategy was that whatever such telephone number as is placed in the first of the three telephone number boxes is considered a potential RoboCall target (none of the boxes were considered candidates for text messaging, in part, because that's an offering that came later). This scheme continues as the first option. Thus, if you pick that first radio button in the GREEN section:

. . . ServiceDesk will proceed with that same original strategy.

If by contrast you pick the GREEN section's second radio button:

. . . the expectation is that it will be your office's practice, if you wish for the contents in any of the three telephone number boxes to be available for SMS texting and/or RoboCalling, you will explicitly so designate that box.

It's important to understand that, if using this scheme, the system will not automatically assume any of three boxes are suitable targets. Explicit designation is required for ServiceDesk to see any as such.

This obviously raises the question: how do you designate any particular telephone number box for potential SMS texting and/or for RoboCalling?

It's done by adding a little snippet of appropriate text into the TelNotes section that's in the corner of each telephone number box. The text that's needed is "TxtTo" for designating a SMS target, or "RoboTo" for designating a RoboCall target:

Please note it's perfectly permissible to have other text in these TelNotes boxes (i.e., besides the special-designating text). Other text will not interfere. ServiceDesk simply looks to see if the special text is anywhere in such a box (it doesn't even matter if it runs on, without spacing, against other text). Please also note that in the Callsheet context (which is where this information is typically first being input), when you click into a TelNotes box, there is dropdown from which you may click to instantly insert the magic-designating text (on typing, it's realized this should be in the JobRecord context too, we'll add it there):

The "Home" and "Work" insertion options are provided just for your convenience. They have no "designation" function. ‍

‍In regard to the RED-ISH section in this settings area (which governs email box treatment), the first little sub-frame invites you to pick: (a) a strategy whereby you place an asterisk next to any item in the email box that you want to have used as an auto-communication target (that's obviously the first radio button there);

or (b) a strategy whereby, if you pick the second radio button in this first frame, the picking strategy will be further defined by your pick from among radio buttons in the second sub-frame:

Please note that ServiceDesk allows you to put more than than just email addresses into a JobRecord's "email" box. In particular (and as you may note is implied by selections in the second frame as shown above), you may also put telephone numbers in such a box. This might indeed be suitable if the customer has provided you with a telephone number for the specific purpose of texting, and if you were not using explicit designation for telephone boxes. The reason is because, if using the second first-frame strategy for a JobRecord's email box, ServiceDesk will assume that a telephone number in the email box is explicitly for the texting purpose.

Regarding communication-target-scheming generally, please note you may, on the one hand, pick a set of strategies that allows you and your office personal to avoid any need for explicit designation of targets (relying instead merely on how items are placed in a JobRecord and logic that flows therefrom). Or you may pick a strategy that allows you and your personnel to be very explicit and direct in your designations. You may even pick a combination.

Please decide what strategy is best for your circumstances, and set accordingly. Then, please further assure all your office personnel know how they must proceed in setting up JobRecord contents, so as to assure ServiceDesk is able to accurately deduce what telephone numbers area appropriate targets for SMS texting, which for RoboCalling, and which email or emails are appropriate for emailing via automated communication.

The structure that allows you to pick from among multiple schemes (in particular, schemes by which ServiceDesk deduces permissible automated-communication targets) was first developed for sending Appointment-Reminder/Confirmation-Requests (okay, we hate how long that expression is, but we've not come up with a sufficiently-communicative shortened substitute).

Having a created that structure, we adapted it to several other contexts of sending communication, such as: (a) sending notice to customers when parts arrive (and with optional request to click on a link so as to schedule); (b) sending initial requests to schedule on jobs dispatched by third parties; and (c) in the SD-Mobile context, when the tech wants to send an "I am on my way" communication (aka "tech call-aheads").

In these contexts the system uses the scheme and structure that you've specified, per the prior section, as the general basis in regard to what's offered to the user, as "send-to targets," for the manually-initiated communication. But there's a difference. Specifically, since a human is involved in these contexts, the system looks to see, for each potential send category (i.e., SMS, Email and Robo) if there is any target scheme-designated or implied by the setup. If not, the system will offer to user whatever otherwise as available available for texting, RoboCalling or emailing.

Most recently, we've added another context that uses your Communication-Targets-Selection-Scheme. It's the system (see here) that auto-sends communications to your customers waiting parts, to assure you're them still waiting, haven't forgotten them, etc.

It's possible, having setup your Communication-Targets-Selection-Scheme, you want to see exactly what result it produces in regard a particular textual setup you happen to have created in a particular JobRecord. We made a function for that. Because this is a somewhat obscure function, we made access to it likewise somewhat obscure. It's nevertheless easy to do, if you simply know the method:

You'll get a little dialog box that perfectly informs:

It's possible, for a particular automated (or semi-automated) operation, you don't want to use all three communication modes that ServiceDesk offers. Maybe you only want to use emails, for example, because they're completely free. Maybe you don't want to use RoboCalls because you personally dislike that instrument. Maybe you want to use all three modes, but with certain preferences and contingencies. Or perhaps your preference fits even a different structure.

As an example, maybe you want to send communications via email, so long as a permissible email target exists. Failing that, perhaps you're next preference is to use SMS texting, so long as there's a permissible target for that, and to revert to use of RoboCalling only if neither of those first two methods avail themselves. Or, perhaps you want to do both Email and SMS if both are available, then revert to RoboCall only if neither are, etc.

The general point is your preference may be any of several different possibilities in such regard. Since our name is indeed "Rossware," it follows, naturally, that we want you to be empowered to realize precisely your preference, whatever it happens to be. Accordingly, we have created the means.

Specifically, we've created a matrix type interface that allow you to be very precise in specifying whatever is your scheme of preference.

To access this matrix, go to the same larger interface that described in this document's first section. In other words, go into your Settings form (Ctrl-F1), and click on the blue button labeled "Setup for Automated Customer Comms." You'll then see that same larger interface, but now we want you to click on the button shown here:

This brings up still another interface, that you'll see looking very similar to this:

The simple idea in the above matrix is the system will seek to send an automated communication using all such target types as you specify on Level-1. If it finds one or more targets matching to a type you've specified on Level-1, it goes no further. If it does not find such a target, it then goes to Level-2, and so on.

Thus, with the arrangement set as per above, the system would send a SMS if in an applicable JobRecord a SMS target is found (according to such scheme as you've defined and according to such textual arrangement as is in the JobRecord, see here). It would also send a email if similarly finding a suitable email target. If it found either, it not not proceed to the next level. If, however, it found neither, it would then proceed in seeing if the JobRecord (along with the logic of the scheme you selected) offered a RoboCall target. If so, it would then send via RoboCall.

If, contrary to such scheme as is shown above, you wanted all three communication types to go to the extent suitable targets were available in the JobRecord, you'd simply arrange all three communication types in the top level. If you wanted preference for email first, and then SMS, and only RoboCall as a last resort, you'd have email in Level-1, SMS in Level-2, and RoboCall in Level-3.

It's pretty simple.

It also turns out that whatever such logic as you dictate in this matrix, the result can be described in a very simple phrasing of words. For example, as shown above the phrase would be "SMS and EMAIL then ROBO." In fact, we've arranged that main interface so that, right under the blue button that you click to show this matrix, it will display the simple phrase that describes the logic you have picked, and which will control when ServiceDesk sends out communication via any automation where it must pick send-to methods and targets:

Please note (as will be further described in the next section) sending of Appointment-Reminder/Confirmation-Requests may be either fully automated (in which case the scheme that's selected here fully controls) or semi-automated. The latter occurs when a user manually invokes initiation of the process from the DispatchMap. Where this is the path, the user will be presented with the same matrix as above-shown, but defaulted to show with such arrangment as you've specified in this Settings context. At such point the user may on an ad hoc basis, if wanted, change the arrangement for his/her immediate initiation of the send.

For sending of assurances on waiting-for-parts, there is no provision for a user select a scheme other than as is setup in this context. Just as with fully automated sends of Appointment-Reminder/Confirmation-Requests, it's the setup here that controls completely.

Sends of these communications may be initiated via any of three manual methods, or via a totally automated path.

The manual paths are all approached from within the DispatchMap:

As a first manual method, you may initiate communication sends on all applicable appointments as pertain to a selected day (typically tomorrow). To do this, go to that day's display in the DispatchMap, and hit Alt-P on your keyboard. That brings up a menu of options regarding multiple things you may with a day's roster of appointments, including this one:

Pick it, then you'll see a standard list of "dispatch" options, including (near the bottom) this one:

Pick it, then you'll see essentially the same matrix as described in the preceding section:

Whereas in the former context your choice in this matrix would create a global setting, here you're choosing the strategy for your immediate send. As mentioned, the setup will default to whatever has been created as the global setting. For most circumstances it's likely best to leave it at that, and simply click "Okay" to proceed.

At this point the system will go through all the appointments in your roster for the day displayed. For each where it's appropriate to do so (it does not, for example, send appointment-reminders on shop jobs), it will send a communication of whatever such type as fits for text in the underlying JobRecord and the matrix of sending methods you've picked. It will provide a dialog box at end of the sequence informing of just what communications have been sent, for each type. Likewise, entries will be added into each applicable JobRecord's narrative history, describing the communication (or communications) sent. If you have a large roster of appointments, the process of going through all in such manner may, potentially, consume many minutes of time.

As a second manual method, you may initiate communication sends on all appointments for the selected day as pertain to a particular set of multiple technicians. Initiate this method same as the above (i.e., go first to the desired day's display in the DispatchMap, then hit Alt-P on your keyboard). But, in this case, choose this option in the dialog box:

Now you'll see a display where you may select each of the particular tech's whose appointments you wish to include in your present communication send:

Pick the wanted techs (use standard Windows multi-select methods), then proceed same as above.

As a third manual method, you may initiate communication sends on just the appointments that pertain to a particular technician. To invoke this mode, begin again in the DispatchMap with the targeted day displayed, then click on the name of the targeted technician where it appears at the top of his list of jobs. Then proceed just the same, from that point onward, as per above. In other words, pick this item in options box that then displays:

. . . and you'll get the same result as when using the other methods, except it will be limited to just the appointments in that particular technician's roster.

For this particular communication animal, we think it generally makes best sense to initiate send-outs manually, as per the above the descriptions. The simple reason is it's usually optimum to initiate these just as soon in the day as you have tomorrow's schedule reasonably solidified. The sooner you can reasonably do the send, the more opportunity there is for recipients to receive your communications, comport their schedules accordingly, complete confirmations, and so on. It's simultaneously true that on some days you'll reach this point sooner than on other days, and there is no practical way for a computer to judge the matter for you. Thus, for optimization of timing in these sends, a human must be involved, judging on each day when you've reached the point where it's sensible to initiate, versus not (and of course initiating just as soon as that point is reached).

Regardless, humans are human. We get distracted, and sometimes forget. That is one of the reasons why the functionality of Appointment-Reminder/Confirmation-Requests gets its own large area in the Comms-Setting interface that is this document's axial focus. We turn our attention now to that precise settings area.

Focusing again on our main Settings interface for automated communications, please notice this yellow section:

As it's captioning implies, this section is all about elements of setup that involve sending appointment-reminder/confirmation-requests. For detailed consideration, we want to first focus on this sub-section:

. . . because it's all about coping with the fact last mentioned: that humans are human. The general notion is that, in this part of sub-section:

. . . you'll setup for ServiceDesk to "kick" one or more persons, at particular times of the day, with an inquiry asking if it's now a good time to manually initiate sends of appointment-reminder/confirmation-requests. You may setup for a succession of up to three different such "kicks." Each can be set for different persons, or all could be for the same person (with each subsequent kick being akin to the "snooze" function on an alarm clock), or any combination you prefer.

Down in this part of the sub-section:

. . . is what you might think of as an emergency fallback. Suppose that by a certain time in the day no one in the operation has initiated sends of appointment-reminder/confirmation requests (i.e., no one has responded to any "kick"). Positively, you don't wan to fail in getting those "sends" out. At this point in day, with no human having done it, there is risk it won't happen at all. Here, in this section, you can set a time of day by which, if the sending process has not already been manually initiated, ServiceDesk will itself auto-initiate, on its own. This assures it gets done, one way or the other.

In this area you simply indicate on what days you want the above-described processes to occur.

Moving over to this area in the yellow section:

. . . this first frame:

. . . is about a very important matter. Unlike RoboCalls (which invite a customer to press a particular telephone key in order to confirm), emails and SMS messages have no similar ability to offer direct and real-time two-way communication. Thus, emails and SMS messages can't offer a "Press 2 to confirm" invitation. Instead, if you're subscribed to SD-CyberOffice (see here), emails and SMS message can offer a "Please click on this link to confirm" invitation. A click by your customer on that link will then, in turn, open a website interface via which the customer may directly confirm, with the result then automatically processed back into ServiceDesk.

For clarity on this matter, some of the functions that are discussed in this document require a subscription to SD-CyberOffice, and some do not. Sending of RoboCalls, for example, requires a subscription (such sending also has an associated fee). Sending of emails obviously does not require a subscription, for such sending (even if initiated by ServiceDesk) does not involve any of Rossware's online machinery (it requires only the online machinery of your own email provider). Anyhow, use of the website interfaces via which a customer online confirms his or her appointment requires subscription to CyberOffice.

Anyway, if you're not subscribed to CyberOffice, you're not permitted to use those online resources, so in such a case it would not make sense to pick the second option above. The alternate option is for the communicative text to instead ask your customer to reply back via the same communication mode in which the appointment-reminder was received (or, alternatively, to simply call the office). This is obviously far less automated, for someone in the office must react manually to any such communication that comes back, go manually into ServiceDesk to flag the confirmation, etc. Regardless, if you're not subscribed to SD-CyberOffice, the first radio button (per above) provides a perfectly usable configuration.

This second frame:

. . . is one where you'll almost certainly want to normally work with the second option picked (i.e., not the first as shown). The only likely exception would be if you're initially experimenting, and for such reason want to at first see and individually approve of each communication, before manually choosing to send it.

This third frame deals with the question of whether you want appointment-reminder/confirmation-requests to go out on appointments that have not been narrowed to a smaller time-frame than all-day:

It's pretty straightforward.

This last little checkbox option:

. . . reflects the fact that many service companies feel less inclined to bend over backward for consumers where the work is being paid for by a third party, as compared to where it's a more lucrative COD job. When customers choose to re-schedule it's often at best inconvenient, and there is perhaps a disinclination to make this easy for less lucrative customers to do. Thus, the above option allows you to preserve the privilege for your COD customers, while nevertheless taking it away for others.

This was initially created in reaction to the COVID-19 pandemic, which produced massive disruption in part supplies. That, in turn, produced a huge burden on service companies in fielding endless inquiries and complaints from customers anxious for repairs that cannot be completed until critical parts arrive.

Even though first made for that need, we're certain the feature's value will continue post-pandemic, though scripts of communication will need to be changed so as to cease mentioning the pandemic as reason for delays.

This feature is specifically managed via this peach-colored section in that same general automation settings interface:

The settings are pretty straightforward. Assuming it's a feature you want to use, simply select in this dropdown the station identifier where you want the process to run:

That is what activates the system. Next, please assure you're set for the sending process to initiate at a time of day, each day, that fits your preference:

Assuming ServiceDesk is running at that station at such time (and on an applicable day, which is the governed by the same applicable-days specification as you set for appointment-reminder/confirmation-requests; see here), ServiceDesk will at such moment self-initiate the process of sending these communications. In particular, it will go through each of your current JobRecords, in particular looking at each that are in "Waiting for Parts" status. For each such JobRecord, it will find the date of the last technician visit, and calculate the quantity of days that have elapsed since then. If that quantity is greater than what you specify here:

. . . ServiceDesk will next look to see if a prior assurance communication has been sent. If no, it will send an assurance message. If yes, it will look to see what was the date when the last prior assurance was sent, and calculate the quantity of days that have elapsed since then. It will then compare that count to what you specify here:

If the quantity of days is greater than your above specification, ServiceDesk will send a repeat assurance, much as above-described.

In regard to such forms of communication as are used in these sends (i.e., SMS, Email or RoboCall), ServiceDesk will follow exactly the same criteria as you've setup to control generally (see three sections above). Thus, it's likely you'll have some JobRecords setup to with preference for and to allow communication via SMS, others via RoboCall, etc. Communications will go off in whatever such form as you have setup to dictate.

You likely want to know that the communications will look (or sound) like.

If the communication is an SMS text, it will look similar to this:

If it's an email, it will look similar to this:

If it's a RoboCall, it will sound similar to this.

Click to Hear Example of RoboCall

In every case, upon completion of a communications involving a JobRecord, ServiceDesk will add an entry into its historical narrative, looking something like this:

Please note, whereas it's beneficial in the appointment-reminder/confirmation-request context to have human involvement in initiating sends, that is not the case in regard to these "assurance-on-parts" animals. For that reason, we have not similarly setup, in their regard, to normally accommodate human initiation. The intent is for normal operation to be 100 percent automated.

Regardless, we realize there may be an odd occasion where you wish to manually initiate (maybe the automatic process did not occur, for example, because ServiceDesk was not running in the designated station at the designated time). Likewise, it's possible you may want to a test to see what the communications would be, without actually sending them. We've accommodated for both needs. But, because we think these are somewhat obscure needs, we've made the path to accommodation likewise somewhat obscure. Regardless, if you float your mousepointer over the frame portion of that peach-colored frame, you'll see a ToolTip, like this:

Simply do as the ToolTip suggests (i.e., right-click on the frame), and you'll see a dialog box like this:

If you choose to "Invoke the Real process," that's exactly what the system will do, albeit with one difference from when the process is invoked via pure automation. There will be a dialog box at the end that informs of how many communications of each type were sent, and on how many different JobRecords.

If you choose to "Just Fake the process," ServiceDesk will run through the routine in much the same manner as real -- except, instead of genuinely sending communications, it will instead write descriptions in a document as to what would have been sent if the process was real. At the end of that routine, you'll be queried as location where you want to save this document, then ServiceDesk will offer to open it for you.

We hope you'll find yourself loving such elements of automated communication as are here described. Likewise, we hope you'll gain enormous benefit.