Parse support emails

A helpdesk turns each email into a ticket, but the ticket starts as free text. Someone still has to read it, decide whether it is a refund or a shipping question, find the order number, judge whether it is urgent and set the right fields. Built-in rules work on keywords, and customers rarely use the keywords a rule expects. "The carafe arrived in pieces" is a damaged item claim without the word damaged in it.

ParsedMail reads the email for meaning and returns the fields you define. Your helpdesk keeps doing what it does well, the conversation with the customer, and gets structured data next to it.

• Intent as an enum with your own options. The model picks one of them, never a new label, so routing rules stay simple.
• Urgency as an enum such as low, normal and high, described in plain English: "high when the customer mentions a deadline, a safety issue or a repeated contact".
• Order ID, invoice number, account email as strings and email fields, ready for a lookup in your store or billing system.
• Booleans such as wants_refund or mentions_chargeback, which make escalation rules explicit.
• Summary as a short string, useful as the first internal note on the ticket.

Quoted replies and signatures are ignored, so on a follow-up the fields describe the newest message, not the whole thread. Fields the customer did not provide, such as a missing order number, return null.

The usual setup copies support mail to ParsedMail alongside the helpdesk, then updates the ticket when the JSON arrives:

1. Support mail goes to your helpdesk as before. A BCC or forwarding rule sends a copy to the ParsedMail inbox.
2. The webhook arrives with the parsed fields, the sender and the subject.
3. Zapier, Make or n8n finds the ticket by requester email and subject, or by the Message-ID, and updates it.
4. Zendesk gets custom field values, tags and priority through its ticket update step. Freshdesk gets type, priority and custom fields the same way. Help Scout, Gorgias and Intercom follow the same pattern.

Teams with their own support tool can call the email parsing API synchronously with POST /v1/parse and set fields before the ticket is even created.

A support address receives more than support requests: sales inquiries, partner offers, job applications, invoices from vendors. On Growth and Scale, classification lets one inbox hold several schemas, for example support request, sales inquiry and vendor invoice, and picks one per email. Sales inquiries can then flow to the lead email parser setup and invoices to the invoice email parser setup through the same automation. Emails that fit no schema go to the review queue.

Some decisions should not be fully automatic. Set a confidence threshold on the inbox, 0.80 by default, and mark fields such as intent as required. On Growth and Scale, an email under the threshold goes to the review queue, where a team member with the reviewer role sees the original email next to the extracted values, corrects them and approves. The webhook then sends the corrected values. Read more about the human review queue.

Support emails contain personal data. Raw emails are kept for the retention period of your plan (30 days on Starter, 90 days on Growth, configurable up to 365 days or zero retention on Scale), and the parsed JSON stays in your account. Emails are never used for model training. Scale adds SSO, an audit log and a data processing agreement. Details are on the security page.