CODEWITHSUNDEEP
mailgunemail
Yamaha32088
Yamaha32088

Reputation: 4163

Unobtrusive way of tracking emails tied to a ticket/record

I am building an application that will allow our internal Sales, Customer Service, and Tech agents to send and receive emails inside our custom CRM. So far the way I have been doing this is by using Mailgun and setting up a subdomain such as send.example.com and then for each record I want to tie email communication back to I generate a unique email address that looks something like this [email protected] I parse the email address by splitting it on + and looking up those records in the database. This is working very well so far in testing, however I am worried about actually rolling this method out to production for a couple reasons.

  1. Spam. I am not sure if that email address will look spammy to some email clients/spam filters.
  2. I think it is probably going to be odd to customers receiving messages from these strange email addresses. Even if I set the From header to something like Testing Person <[email protected] and the Reply-To header as the unique address.

This seems like the easiest way to link up emails because the alternative I thought of is to do what I have seen in other ticketing systems where it appears they have a unique number in the body of the email and it typically says to "reply above this line" I assume the way that these types of ticketing systems work is they strip everything out and parse the number to tie the record back. I feel like this method would be more prone to error just because someone could delete the body of the previous reply and cause it not to recognize the email.

Is there another method I am not thinking of or is this basically the only two methods that exist? I am curious what others have done in the past and how often rogue emails get dropped due to someone not replying to an email correctly.

Upvotes: 1

Views: 71

Answers (1)

Tony Chiboucas
Tony Chiboucas

Reputation: 5683

Just make the users feel good about it.

While the email addresses you're generating will look weird, spam filters probably won't care (as long as you're not spamming). Remember that most of them look for trends and behaviors of a specific MX record (email domain).

The users are your target

If users understand what they are looking at, and don't mind the email, they won't click that SPAM button, and you should be fine.

If you want this to look clear to your users, go ahead with something close to what you're currently doing, but tokenize the specific issue a little more clearly. Lastly, communicate to your user what this is. i.e.: put a descriptor in the address, like 'support'. I'd use support over quote simply as a matter of priming the user for getting help, rather than getting sold.

  1. Keep with the user-name as a from email.
  2. ditch the +, and use _ instead, it won't feel as odd.
  3. Tokenize the issue-key and apply to a combination of:
    • reply-to
    • subject

Example:

issue-key as: issue-type-char issue-name

email as : user.support_issue-key

From: [email protected]
Reply-To: [email protected]
Subject: Update Regarding Your Sample.com Inquiry [QABC123]
Body: ... To ensure your response is properly and promptly address, please reply to this email **without changing the subject** of the email. ...

Tokenize, Prioritize, Assign

You're essentially tokenizing three pieces of data:

  1. User (email)
  2. Issue-type
  3. Specific-issue.

... so make sure your system trys to do the same in reverse:

  1. Does this match a specific issue? Yes --> append & prioritize
  2. Does this match a specific issue-type Yes --> create & prioritize
  3. Does this match a specific user? Yes --> create & prioritize
  4. Is this probably spam? No --> add to backlog for triage

Intelligent matching

At each of those steps above, remember to check all four (more if you dive into email headers) places to try to determine a match:

  1. To email address (user, issue-key)
  2. Subject (issue-key)
  3. Sender (user)
  4. Body
    • usually includes email chain, so there can be (user, issue-key) in there.

In the end, this is all about organization

Users can do all sorts of things, like send a new email to [email protected] or [email protected]. Do your best to ensure these are recorded as issues for that user. Give support techs a tool to move these onto an existing issue. Have someone going through that backlog to triage real issues, and get them assigned.

Find a way to try to prioritize specific issues, and give the support-techs a list of USERS according issue priority. You'll find this step alone will save a lot of time.

Lastly, if your system does do any degree of routing to specific techs, try to match the same user to the same tech as often as possible. You might even take this a step further, and assign a tech to a user, then allow techs to unassign themselves with a logged "reason".

Upvotes: 1

Related Questions