The general concept in this utility (abbreviated as “EDR”) is simple. Its purpose is to automate 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 that are 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, every few minutes the utility checks the email inbox you have specified for new emails from the specified sender. When it encounters any, it opens the email, parses the contents on basis of the expected content-format you have specified, and plugs each field appropriately into a new ServiceDesk Callsheet.
The further concept is you simply 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 simply see new Callsheets appear (representing new dispatches that the underlying entity has sent to you), and of course you process accordingly.
Prior to 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 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 for the EDR to work by looking in your Outlook (or similar) Inbox, you are on your own in regard to troubleshooting any such issues as may arise.
The reason we built an alternate system (and no longer support the old) is because, increasingly, security interdictions began making connection to a local email client very problematic. So, we made a new and very trouble-free mode that involves connecting to a Gmail Inbox, which, happily, is free. This mode is very trouble-free, and is also quite easy to setup.
Regarding such setup, specific instructions are in the last section of the How to Setup Email Handbook. A handy alternative path to that handbook 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:
Basically, those other instructions will tell you how to setup a Gmail account whose specific purpose is to receive dispatches that you wish to have the EDR connect to for purposes of automation. Then, within the above-shown window you’ll place the credentials (username and password) as applicable to that account. Finally, you will need to instruct the entity that is sending you dispatch emails (and for which you are setting the EDR to receive them) to change their own 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 quite 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 might be added information of importance in that email, just double-click on the link, and you can instantly view the entirety of text as actually present in the dispatching email.
When you click on the EDR’s dropdown, you’ll see we have configured with ability to process dispatches from a number of different entities:
While it’s possible 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, the concept when wishing to connect with more than one entity is simple. You just run multiple and independent instances of the EDR, each set to work with the particular entity that you want it to work with (and, yes, you may have each such entity sending email dispatches to the same Gmail Inbox).
But there is a little issue that 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, if you run a second instance from that same desktop, it’s going to pick up the settings that you entered in regard to the prior instance. You’ll need to change the settings to what you want for this second instance — which is sort of fine, except when you re-start the first instance, it’s now going to pickup 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 prior to 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 own 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 latter, the 4.6 series of EDR offers a new scheme.
Specifically, you can place an identifier in the shortcut that’s used to start the EDR. With any particular such identifier, the instance of EDR that runs when you use the shortcut will deem itself as unique-in-regard-to-this-identifier, and will save and read its settings accordingly.
To create this identifier, first create a desktop shortcut for any particular EDR instance that you wish 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 to your desktop, release the right mouse button, then, from the menu popup, select
That makes your shortcut. Once it’s made, we suggest you re-name 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, just 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. In fact, any such instance will show its identifier in its title bar:
So, suppose you want to run three different instances, so as to automate dispatch reception with three different entities. Just make a unique-identifier shortcut for each of the three, each appropriately labeled, and start each from its unique shortcut.
All that’s described in this section is great if you intend to start each instance manually by double-clicking on a desktop shortcut. If, however, 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 a shortcut is invoked by Windows from the Startup folder. There is a way around that. It involves using something called a batch file, which is actually very easy. Just open Notepad or similar and type one line of text similar to this (but with path to the utility as suitable to your circumstance, and title of the intended instance also suitable):
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 normal way of making 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 $17/month subscription.
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 as directly connected to the fact there is multiple-instance use. In some
cases, such users have changed computers, 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 own multiple-instance setups (and if in such management you do not egregiously increase the support burden that’s 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 if you’d volunteer to pay (at least commensurately to your increased burden) for one or more added-instance subscriptions.
Please note that a moderate amount of assistance as connected with multiple-instance setup and without paying more than the $17/month) will be considered just fine.
At the end of the day, 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.” We’ll here provide some context for why this option exists, and how it may be used.
Often, service companies have a made a large investment working to make the phone ring, with 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 very silly. It is practically foolish.
It is in recognition of this that 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 directly do so. 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 instruction allowing them to totally 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 (rate at which potential new service orders are made into real service orders) for those hours when you would have otherwise been presenting callers with a voice message.
But, if so employing an answering service, there is an issue of 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. Not efficient, obviously.
So here is the solution.
All answering services use software for call takers to enter information from the person who is calling. These software systems allow the answering service to create a customized call-taking template for each different client (e.g., you). They also
allow the answering service to 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 you have your answering service setup their template (as configured specifically for your company) with a given set of field headers which match what the EDR’s “Answering Service” template is prepared to properly parse. You further have them set for each message (or completed service order) to be emailed to the particular Gmail account that you have setup for reception of dispatched emails. Then you configure an instance of the EDR to receive and process those particular emails from that Gmail box.
The field name/titles that the EDR’s “Answering Service” format is prepared to accurately parse are as follows:
You do not have to have your answering service setup for use of 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 as 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 for is limited. It’s possible you receive dispatch emails from one or more entities that are not in 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 significantly-large 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 significantly large, we do not generally make it unless we have learned that a significant quantity of users will benefit.
As of finally having added First American to our list in July 2016, we are at this point unaware of any other email-dispatch-sending entities from whom a significant quantity if our clients receive dispatch emails. For such reason, it is not presently on our agenda to add any particular other entity.
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 are receiving a significant quantity 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 especially controls where a project is going to be significantly time-consuming (as is, indeed, developing parsing for any new dispatch format).
Nevertheless, there is a basis where very occasionally we’ve found it suitable to depart from our normal “for-the-best-good-of-all” prioritizations. It is where a client with unique need desires to pay us directly for the desired programming investment.
Thus, if you need automation of dispatch emails from, say, XYZ Home Warranty (that’s just a fictional name), and if it’s not evident a significant quantity of other Rossware users likewise needs this, an option would be to directly pay us for the needed programming. 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 in the range between $300 and $1500).
As an alternative, just let us know you are voting for XYZ Home Warranty (or other entity). We keep an informal tally of such requests. If and when our tally shows that a significant quantity of y’all have a significant desire to have XYZ Home Warranty added (or other entity), we’ll do it on our dime, and as a priority too.
*As of July 2016, the list is as follows:
To whatever extent you receive a significant quantity of dispatch emails from an entity which the EDR is prepared process, we believe you will find it is a wonderful tool. At end of the day it is very simple, easy, and effective. It can save you from a ton of otherwise dreary work, and dramatically increase your accuracy as well.
