Say you have a website with users who have accounts. Those users email you sometimes. What if you could parse that email for more context about that user, their account, and what they might want?
There are email parsing services out there. For example, Zapier offers Parser, which is free, with the idea being that you use Zapier itself to interconnect that data with other apps.
mailparser.io is another service just for this.
Same deal, you send the emails to them, and from within that app you set up parsers and do all the processing you need to do.
That might not be exactly what you need.
Perhaps your goal in parsing an email is to extend the data available to you right in your email client.
Gmail is a pretty huge email client. I just noticed that they have released and official way to make “Gmail Add-ons”:
Gmail add-ons are developed using Apps Script, a scripting language based on JavaScript that serves as a connective platform between Google products like Docs, Sheets, Drive, and Gmail. Every Gmail add-on has a corresponding Apps Script project where you define your add-on’s appearance and behavior.
That might be just the ticket for those of you looking to get your hands on email data, do stuff with it, and have a UI for doing stuff right within Gmail. There is a marketplace to check out with existing apps. The Trello one seemed pretty compelling to me.
Plus:
The contextual cards you create for your add-ons work for both web and mobile versions of Gmail. This means that you don’t need to create separate web and mobile versions of the add-on—the same code works everywhere!
Personally, I make pretty heavy use of Front, which is like a shared team inbox superapp.
Front offers a plugin system as well, which adds your own custom panel right into the app itself and gives you all that programatic parsing stuff you need to get into emails (or tweets or whatnot).
We use it at CodePen to figure out who’s emailing us (from the perspective of our own app) and show some contextual information about them, as well as provide some quick common actions that we might need.
Another thing to consider is how the emails are being generated at all. For example, do you offer customer support by just saying “email us at [email protected]”, or do you have them fill out a form which generates an email? If it’s a form, that’s, in a sense, parsing an email before it’s even sent, meaning it has structure and potentially programattic access to individual fields.
An example of that might be using a Wufoo form for your support and then using the API to access the data as needed. Maybe you can skip email parsing entirely.
