There was a simulteanous conversation happening in both the ASCII Autotask mailing list and Facebook Autotask User Group about how to best route inbound vendor emails for specific clients.
This is a common problem. While it would be great, it’s not 100% possible to control the subject lines of automatic vendor emails, alerts, etc. Let’s start off with an example. To begin with, while Giant Rocketship is a SaaS vendor that builds Autotask PSA improvements, we are based on a 20-year IT MSP.
So we’ve had the issue where you setup a vendor account or a network device and you have to live with its subject line, e.g., “network device error”. Or it could be a vendor email for a product that many clients use. The specifics don’t matter so much as this is a fact of life.
Let’s discuss the solutions for how to ROUTE the emails so they stop being spam and start being actionable. Our test case is vendor X that sells network device Y that sends out emails with subject lines “network device error.” You have control over the email To, but not the subject line.
Here are our solutions:
Route email@example.com to Mailbox
This is the most common solution. The vendor notices and errors go a mailbox in 365 or Google Apps. You either ignore them, letting them fill the mailbox over the years, or, for a select few, you have a triage/dispatch or tech assigned to review the mailbox, delete spam/newsletters, and forward actual ticket-worthy items.
The pros are that this is very simple to implement. The con is that this is external to your normal helpdesk process of doing triage/dispatch via Autotask.
Route firstname.lastname@example.org to Autotask
In this scenarios, all emails go to clients@ and your triage/dispatch handles them. This is actually quite viable, especially if you are a smaller MSP. clients@ can go to a mailbox, but, even better, send them to a special queue in Autotask “Inbound Vendor Notices” so that your helpdesk@ is reserved for human inbound emails.
The pros are that this is still relatively simple and, extra benefit, you stay “in channel” and your triage/dispatch continues operating normally, with just an extra queue to watch.
Use Email Plus addressing: Route email@example.com to Exchange Transport Rules
This is a powerful solution mentioned by Tony Thomas on the ASCII Autotask mailing list. Use email plus addressing (let’s just say email+) and the relatively simple Transport Rules in Exchange/Exchange Online. So, let’s say you have a client Mega Corp LLC. Like many MSPs, you’ll have a “short name” version, like MC for this client. Then setup all vendor notices/alerts to go to clients+MC@msp.example.com, and have your Exchange Transport Rule update the To: address along the lines of: MCfirstname.lastname@example.org. To keep email processing simple, add “MCemail@example.com” as a Contact under the Autotask CRM Company Mega Corp LLC. Now, emails to that will create a ticket in Autotask for MegaCorp.
The pros are that you have reduced triage/dispatch redundant work because your email processor handles assigning the right CRM Company to the ticket. Triage/dispatch then does the EXACT same thing they do for normal helpdesk tickets. The con is that you have to manually edit your Exchange Transport Rules as you add/term customers.
Use Email Plus addressing: Route firstname.lastname@example.org to MSPIntegrations Email2AT
Similar to the above, but this is if you’re an MSPIntegrations Email2AT user (we are big fans). So with Email2AT, you can parse out just about everything, and that includes the To: address. So alter the above so that the To: is clients+<COMPANY.ID>@, e.g., clients+3434343434@. The <COMPANY.ID> is the ID of the CRM entry in Autotask for the customer.
Then, in Email2AT, parse out the COMPANY.ID, automatically assign the new ticket to the right company, and resume life.
The pros here are similar to the above, but with the extra benefit that this approach dynamically shifts with your add/term of clients. So long as you use the COMPANY.ID in the email+ address with the vendor, Email2AT will ebb and flow with your CRM.