EmailDispatchReceiver Guide

The general concept in this utility (abbreviated as “EDR”) is simple. Its purpose is to automate the reception of dispatches from parties that send dispatches to you via email. The basic idea is as follows.

You set the utility to look for emails (i.e., emails in “un-read” status) at a particular email inbox and as sent from a particular email sender. You also indicate the sender format you expect such emails to be in (e.g., American Home Shield, First American, etc.).

Based on the above, the utility checks the email inbox you have specified for new emails from the specified sender every few minutes. When it comes to any, it opens the email, parses the contents based on the expected content format you have specified, and plugs each field appropriately into a new ServiceDesk Callsheet.

The further concept is you keep this utility running from one of your stations, in the background and unseen, as it churns away dutifully doing its work. From your perspective, you see new Callsheets appear (representing new dispatches that the underlying entity has sent to you), and of course, you process them accordingly.

Before 2012, the EDR was programmed to connect solely to a Windows-installed email client (e.g., Outlook or Outlook Express). Though it can still work in such a fashion (settings are there for it, and you are free to use them), we no longer support this mode. In other words, if you wish to set the EDR to work by looking in your Outlook (or similar) Inbox, you are on your own regarding troubleshooting any such issues that may arise.

We built an alternate system (and no longer support the old one) because, increasingly, security interdictions began making connections to a local email client that were very problematic. So, we created a new and very trouble-free mode that involves connecting to a Gmail Inbox, which is free. This mode is very trouble-free and relatively easy to set up.

To let you know, specific instructions are in the last section of the Setup Email guide. A handy alternative path to that guide is in the Email setup window that you may obtain by clicking on this button within the EDR:

Then, in the email setup window itself, click on this button:

Those other instructions will tell you how to set up a Gmail account whose specific purpose is to receive dispatches that you'd like to have the EDR connect to for automation purposes. Then, within the above-shown window, you’ll place the credentials (username and password) applicable to that account. Finally, you must instruct the entity sending you dispatch emails (for which you are setting the EDR to receive them) to change their setting to use this new Gmail account as their dispatch-send-to address.

Then, upon having filled in its three simple boxes, you let the EDR run in the background and do its work. This is all that is generally required.

We are careful in designing our parsing program code to make it accurately grab and insert into a Callsheet all the unique information that is particularly relevant to each incoming dispatch. Regardless, there is always a possibility that some element of significant information (as present in the email) was not parsed and placed into the Callsheet.

To help you deal with this possibility, the EDR always creates a copy of the underlying dispatch email and includes a link to that copy in the Callsheet that it creates:

If at any point you think there is added information of importance in that email, double-click on the link, and you can instantly view the entirety of the text as actually present in the dispatching email.

When you click on the EDR’s dropdown, you’ll see we have configured with the ability to process dispatches from several different entities:

While you may only wish to automate dispatches in connection with one of these, there is a good chance you’ll want to automate dispatches with more than one — perhaps even with several.

In general, connecting with more than one entity is simple. You just run multiple independent instances of the EDR, each set to work with the particular entity you want it to work with (and, yes, you may have each such entity sending email dispatches to the same Gmail Inbox).

However, a little issue arises with multiple instances. It is that any particular instance saves its settings to a file that’s unique to the desktop where it is running. So, running a second instance from that same desktop will pick up the settings you entered regarding the prior instance. You’ll need to change the settings to what you want for this second instance — which is okay, except when you re-start the first instance, it’s now going to pick up the settings that were saved by the second instance, so you’ll have to change back to what’s wanted for the first instance, and so on.

To avoid this kind of “stepping-on-toes” between instances, we invoked a particular suggestion before July 2016 and the 4.6 series of EDR. The suggestion was to run each of multiple differently-wanted instances from different desktops — so that each would have separate and different places for their differently-wanted settings. This solution works but defies what some users consider ideal in setup strategy, which is to have all background-running utilities running from the

To accomplish this, the 4.6 series of EDR offers a new scheme.

Specifically, you can place an identifier in the shortcut to start the EDR. With any particular identifier, the instance of EDR that runs when you use the shortcut will deem itself as unique-in-regard-to-this-identifier and save and read its settings accordingly.

To create this identifier, you can create a desktop shortcut for any particular EDR instance you want to make unique.

Our favored method for creating a shortcut is to find the program file in the working (typically, c:\sd) folder where it resides, click down with your mouse button, drag it to your desktop, release the right mouse button, and then, from the menu popup, select

That makes your shortcut. Once created, we suggest you rename the shortcut to reflect its unique intent (e.g., “EDR for First American”).

With that done, right-click on the shortcut and pick. In the shortcut’s Properties window, add some unique identifying text as a further word or words following the shortcut’s target path:

Then, of course, click on OK.

Now, you have a shortcut that will start the EDR as a unique instance — saving and reading its settings according to the unique identifier you’ve placed in the shortcut. Any such instance will show its identifier in its title bar:

So, you want to run three different instances to automate dispatch reception with three different entities. Make a unique identifier shortcut for each of the three, each appropriately labeled, and start each from its unique shortcut.

All this section describes is great if you manually start each instance by double-clicking on a desktop shortcut. If you want to start multiple/different instances automatically on Windows bootup, it turns out there is an issue. In particular, we have discovered Windows does not pass through command-line arguments (such as are needed for this scheme) where Windows invokes a shortcut from the Startup folder. There is a way around that. It involves using something called a batch file, which is very easy. Just open Notepad or similar and type one line of text similar to this (but with a path to the utility as suitable to your circumstance and the title of the intended instance also suitable):

start c:\sd\EmailedDispatchReceiver Instance

Save it under whatever filename (and at whatever location) you wish, but with the extension .BAT (e.g., BatchFileForEdrInstance1.BAT would be a reasonable filename). Now you have a batch file. Next, make a shortcut to it in the usual way of creating shortcuts, and place that shortcut in the Windows startup folder. Do this for each instance that you wish (varying as appropriate for each instance). It’s as easy as that.

In general, we’d like you to feel free to use multiple instances of the EDR while paying for but a single monthly subscription (as described here).

There is an exception.

There have been instances where some users expect us to do multiple-instance setups for them. This, of course, means an increased support burden is placed on us and is directly connected to the fact there is multiple-instance use. In some cases, such users have changed computers and then wanted us to re-do the multiple-instance setup for them again, and sometimes still again. In cases like this, we’ve felt that (because of such added support as was being demanded) such users should indeed pay for multiple EDR subscriptions (as opposed to paying for just one).

The bottom line is as follows:

If you manage your multiple-instance setups (and if in such management, you do not egregiously increase the support burden placed on us), please plan to pay the single-instance fee.

If, on the other hand, your multiple-instance effort significantly multiplies our support burden, we’d appreciate it if you’d volunteer to pay (at least commensurately to your increased burden) for one or more added-instance subscriptions.

A moderate amount of assistance will be considered acceptable, as connected with a multiple-instance setup without paying more than the monthly fee.

We wish for it to be fair in both directions.

You may notice that one of the email dispatch formats you can pick is “Answering Service.” Here, we’ll provide some context for why this option exists and how it may be used.

Often, service companies have made a significant investment working to make the phone ring, with the potential to receive requests for retail service. How silly is it to let these calls go to a recorded voice message, which has a very high chance of forfeiting the opportunity that otherwise exists to turn that call into an actual order for service?

Answer: It’s ridiculous. It isn't very smart.

In recognition of this, many service companies choose to employ a live answering service, poised to answer the phone at any time (24/7) that the office is not otherwise able to do so directly. The nice thing is that personnel at answering services can be trained to answer as though they are in-office persons and may even be equipped with instructions allowing them to book new service calls for you (as though indeed answered by an actual in-office person).

If you employ an answering service that does this well, it will dramatically increase the call-conversion rate (the rate at which potential new service orders are made into actual service orders) for those hours when you would have otherwise been presenting callers with a voice message.

However, if an answering service is employed, there is an issue with getting caller information from the answering service into ServiceDesk. The old-fashioned method would have been to human-call your answering service and have a person there read information orally as you type it into ServiceDesk Callsheets. It needs to be more efficient.

So here is the solution.

All answering services use software for call takers to enter information from the person calling. These software systems allow the answering service to create a customized call-taking template for each client (e.g., you). They also enable the answering service to be set so that each time a call is received, and a template is filled in, the result is immediately emailed to you.

This is where the EDR’s “Answering Service” format comes in. The general idea is to have your answering service set up its template (as explicitly configured for your company) with a set of field headers that match what the EDR’s “Answering Service” template is prepared to parse correctly. You have them set for each message (or completed service order) to be emailed to the particular Gmail account you set up to receive dispatched emails. Then, you configure an instance of the EDR to receive and process those emails from that Gmail box.

The field names/titles that the EDR’s “Answering Service” format is prepared to parse accurately are as follows:

PayingParty:
Payer Address Ln1:
Payer Address Ln2:
Payer Phone1:
Payer Phone2:
Customer Name:
Customer Address Ln1:
Customer Address Ln2:
Home Phone:
Business Phone:
Product Type:
Product Make:
Date Scheduled:
Description/Request:
Other Notes:
Addtl Address Info:
Model #:
Serial #:
PurchaseDate:
Taken By:
Taken Date:

You do not have to set up your answering service to use all these fields. You may have them use as few or as many as desired. The general thing you must know is these are the particular and precise headers that, if preceding items of text are sent by your answering service, the EDR’s “Answering Service” format will know to interpret the immediately following text accordingly, as it plugs such text into Callsheets.

You will notice that the array of dispatch formats you can set is limited. You may receive dispatch emails from one or more entities that are not on the list. It raises the question: can other entities (particularly any such others as you may desire) be added to the list?

The short answer is yes.

The longer answer is as follows.

It requires a significant programming investment for us to write such code as is needed to accurately parse wanted text from any uniquely new and different emailed dispatch format (plus, further investment is required if/when that entity changes its formatting, which indeed happens from time to time).

Because this investment is significant, we only generally make it if we have learned that many users will benefit.

Regardless, it is likely that others will indeed come up as time goes by. Just as we’ve done in the past, it is our intent, as we learn that a significant quantity of our users is receiving a substantial amount of dispatch emails from some other entity — to that point, we’ll want to make such programming investment as is, needed to accommodate parsing from that entity’s format.

In the meantime, if you have a dispatch-format-parsing need, and if (and at least so far as we know) you’re pretty much the only Rossware client who has it, we hope you’ll understand we always have a large number of programming projects we are seeking to conquer, and generally, we must prioritize toward projects that will benefit more clients, as opposed to fewer. This principle mainly controls where a project will be significantly time-consuming (as is developing parsing for any new dispatch format).

Nevertheless, there is a basis where occasionally we’ve found it suitable to depart from our usual “for-the-best-good-of-all” prioritizations. It is where a client with a unique need desires to pay us directly for the desired programming investment.

Thus, if you need automation of dispatch emails from XYZ Home Warranty (just a fictional name), an option would be to pay us directly for the required programming if it’s not evident that many other Rossware users need this. The dollar amount would depend on difficulty level (some dispatch formats are relatively quick and easy to code for, while others are much more difficult). If you’re interested in a particular format, provide a few samples, and we’ll respond with a dollar figure proposal (typically expect something between $300 and $1500).

Alternatively, let us know if you vote for XYZ Home Warranty (or another entity). We keep an informal tally of such requests. If and when our tally shows that a significant quantity of you all want to have XYZ Home Warranty added (or another entity), we’ll do it on our dime and as a priority.

*As of February 2023, the list is as follows:

• American Home Shield

• Answering Service

• Fidelity National Home Warranty

• First American

• LG Canada

• Mabe

• Michaelson’s Website

• National Electronic Warranty

• Old Republic

• PC Richard

• Warrantech

You will find it an excellent tool to whatever extent you receive a significant quantity of dispatch emails from an entity that the EDR is prepared to process. It is straightforward, easy, and effective. It can save you from much otherwise dreary work and dramatically increase accuracy.