Every time a monitoring alert hits your Autotask inbox, the Add Ticket Email Service (ATES) makes a quiet decision: match it to an existing contact, create a new one, or assign it to your own organization. Get that configuration wrong, and you're not just dealing with duplicate contacts. You're dealing with misrouted tickets, broken billing trails, and client records your team can't rely on.
The tricky part is that none of this fails loudly. When the incoming data doesn't match your records, ATES follows its processing rules exactly, which can mean tickets landing in your own organization, placeholder contacts, and reporting that slowly drifts further from reality with every alert cycle.
Here's what's actually happening under the hood, and what to fix first.
ATES uses a decision tree when processing incoming alert emails. The outcome depends entirely on what's in the XML token appended to the email and how closely that data matches your existing Autotask records.
The three primary matching paths, per the official processing rules, work like this:
Three configuration gaps create most of the issues MSPs see:
<Contact name="Firstname Lastname"/> element, ATES assigns no contact. The ticket gets a note saying no contact match was found, and your workflow rules that trigger on contact assignment never fire.That last one compounds fast. A week of monitoring alerts from a new client can generate a dozen contacts named "Unknown Unknown" before anyone notices.
A contact or organization mismatch at ticket creation isn't just a data quality issue. It affects downstream processes that depend on accurate ticket-to-organization associations.
Contract billing breaks. Autotask contract associations are organization-specific. A ticket assigned to organization ID: 0 (your local org) won't pull from the correct client contract. Time entries on that ticket may not roll up to the right billing period, and you won't catch it until a contract reconciliation or a client dispute.
SLA reporting becomes unreliable. SLA calculations depend on the ticket being associated with the correct organization, which carries the SLA settings. Misassigned tickets either inherit the wrong SLA or none at all. Your reports show green when a client's response times are actually breached.
Workflow rules don't trigger. Many MSPs use workflow rules to notify contacts at ticket creation. If no contact is assigned (because the XML was missing the Contact element), those rules never trigger. The client doesn't get notified, nobody escalates, and the ticket sits.
ATES does log a note in the ticket description when this happens, but most technicians don't read ticket descriptions on auto-generated alerts.
Most ATES problems I've seen come down to three configuration areas that MSPs set up once during onboarding and never revisit.
Organization name synchronization. ATES requires an exact string match on organization names. If your RMM, documentation tool, and Autotask don't use identical client names, every alert from that client will land in the wrong place. Audit your top 20 clients: compare the Customer name value your RMM sends against the exact organization name in Autotask. Even a trailing space causes a mismatch.
XML token Contact element handling. The <Contact name="Firstname Lastname"/> element is optional but strongly recommended, especially if you rely on workflow rules to notify contacts at ticket creation. If you're using a third-party email parser to forward alerts, you can dynamically populate this field using a tag like <Contact name="%msg_fromname"/>. Many MSPs skip this entirely during setup, then wonder why their contact notification workflows never fire.
New contact creation permissions and UDF defaults. When ATES auto-creates a contact, it populates only four fields: First Name, Last Name, Organization, and Email Address. Any user-defined fields (UDFs) marked as required are ignored unless you've set a default value. If your contact UDFs include required fields without defaults, you're generating technically incomplete contact records that may cause validation issues elsewhere in your instance.
Work through this in order. The first two items catch the majority of ongoing data issues.
1. Validate organization name matching
2. Lock down the Contact element
<Contact name="..."/> element%msg_fromname variable is populated correctly before the XML is forwarded3. Audit UDF defaults for auto-created contacts
4. Set up a recurring data cleanup workflow
5. Test your domain fallback logic
ATES misconfiguration doesn't announce itself. It accumulates quietly over months until someone pulls a billing report that doesn't match reality, or a client asks why they never received ticket notifications, or a technician notices that half the alerts from a major client are landing in the internal queue.
The fix isn't complicated, but it requires treating ATES configuration as an ongoing operational process rather than a one-time setup task. Standardize your organization names across every tool that feeds Autotask. Include the Contact element in every alert template. Set UDF defaults so auto-created contacts are complete. And run cleanup queries monthly before the data debt gets expensive.
Your data accuracy is only as good as what comes in at the front door. ATES is that front door for a significant portion of your ticket volume, so make sure your configuration is giving it the right information to work with.
Clean data is also what makes automated dispatch accurate. When every ticket lands with the right organization and contact, tools like Rocketship can triage and assign it to the right technician instantly. If you'd like help auditing your ATES setup, our Autotask Consulting team can help, or grab the free Autotask Data Clean-Up Kit.