Most support still starts in an inbox
Live chat catches the visitor who is on your site right now. It does not catch the customer who wrote to you at eleven at night from their phone, or the one who replied to an order confirmation, or the accounts payable clerk who has your support address saved from three years ago. Those messages arrive in an inbox, and in most small teams the inbox is where support quietly falls apart.
The failure is rarely dramatic. Mail sits unread because whoever normally checks it is on holiday. Two people answer the same message an hour apart, with different answers. A reply lands under a subject line nobody recognises and is skimmed past. None of these are discipline problems. They happen because a shared mailbox has no concept of ownership, status, or a thing being finished.
MyLiveChat can take that traffic and turn it into the same tickets your chat escalations become, so the two halves of your support load sit in one queue with one set of rules. The customer never sees any of it. They keep writing to the same address from their normal email app, and there is no portal to sign into.
What the feature actually does
The mechanism is deliberately small. You point your support address at a mail provider that parses inbound email, and that provider forwards each parsed message to MyLiveChat as a web request. We create a ticket from it. When the customer replies to the thread later, that reply is appended to the same ticket as a comment from the requester rather than starting a second one.
A reply from a requester also reopens the ticket if it had already been resolved or closed, which is the behaviour you want: the customer telling you it is still broken should put the conversation back in front of an agent rather than disappearing into a finished record.
Everything after that is ordinary ticket work. The message lands in the same helpdesk queue your chat escalations do, gets assigned, tagged, and closed the same way, and appears in the same reporting.
The two addresses that make it work
Routing is done by the recipient address, and there are two shapes of it.
The first identifies your account. The Email to ticket screen shows you the exact address, and it carries a tag with your site number in it, in the form [email protected]. Anything sent there becomes a new ticket in your account. That tagged address is what you hand to customers as your contact address, and the domain part is a sub-domain you set up at your mail provider, not one of ours.
The second identifies a ticket. Replies come back to an address tagged with the ticket number instead of the site number, which is how a message that arrives days later is matched to the conversation it belongs to. Standard mail threading headers are used as well when the provider passes them through, so a customer whose mail client rewrites the subject line still lands in the right place.
One rule about replies is worth knowing before it surprises you: a reply is only appended when it comes from the address the ticket already knows as the requester. A customer who writes in from their work address and then replies from a personal one is not silently merged into their own ticket, and neither is a stranger who guesses a reply address. That is the correct trade, but it does mean the occasional legitimate message is refused, and the audit log is where you will see it.
Setting it up with a mail provider
The dashboard screen is at Tickets, then Email to ticket, and it walks the setup in three steps: it shows you the webhook URL to hand your provider, the tagged support address to hand your customers, and provider-specific instructions.
With SendGrid the work is in Settings, then Inbound Parse. You add a host and URL, name a receiving sub-domain you control, paste the webhook URL as the destination with ?provider=sendgrid appended, then add the MX record SendGrid gives you for that sub-domain in your DNS.
With Postmark you set up an inbound stream, forward your support address to the inbound address Postmark issues, and set the stream webhook to the same URL with ?provider=postmark. Turn on the option that includes raw email content in the payload, because that is what carries the threading headers.
Either way, the last step is the one people skip: send a real test message and confirm it appears. The screen shows the recent audit rows directly underneath the setup, so you get an answer in under a minute rather than discovering next week that MX record never propagated.
If you run your own mail server
You do not have to use a hosted parser. If you run your own mail transfer agent you can post the message yourself, formatted as JSON with the sender, recipient, subject and text body, and include the threading headers if you want replies to match. There is also an optional shared secret your administrator can require, so the endpoint is not simply trusting whatever reaches it.
This route is more work and it is the right one if your mail already passes through infrastructure you control, or if the compliance answer for your industry is that customer mail does not transit a third-party parser.
Reading the audit log
The screen carries three counters, for inbound messages in the last day, inbound in the last week, and failures in the last day, and then the most recent messages with an outcome against each.
Two outcomes are the happy path: a message that became a new ticket, and a reply that was appended to an existing one. The rest are worth learning, because each points at a different fix.
A message with no usable recipient, or a recipient we do not recognise, almost always means the address is not the tagged one. Someone published the plain address, or a forwarding rule rewrote the envelope and stripped the tag. A refused reply means the sender did not match the requester on that ticket. A throttled message means one account sent an unusual volume in a short window and the rate limit did its job.
The counter that deserves a weekly glance is failures in the last day. Zero is normal. A number that appears the same week you changed a forwarding rule is your answer, and a number that climbs slowly usually means customers are replying from addresses other than the one they wrote in from.
What it does not do
It does not replace chat, and it is not a shared mailbox with a nicer interface. Mail that arrives becomes a ticket, and everything that happens afterwards happens in the ticket, not in the inbox. If half your team keeps working out of the mailbox, you now have two systems and the confusion is worse than before you started.
It also does not give customers an account. There is no portal login and no password for them, by design. If somebody needs to see their own history, that is a conversation about what you send them, not a feature you enable.
And it does not decide what is worth being a ticket. Newsletters, bounces and vendor mail that reach the address become tickets like anything else, which is a good reason not to point a general-purpose company address at it on day one.
What to measure
Failures in the last day, weekly, as a health check rather than a metric. Anything other than zero has a cause you can name.
The share of your ticket volume that arrives by email rather than chat. It tells you whether the inbox was a side channel or the main one, and it usually surprises teams who assumed chat was carrying everything.
First response time on email-origin tickets compared with chat-origin ones. They should not match, and the gap is the honest number to publish in your own service commitments rather than one figure that flatters the fast channel.
Email is not the only front door that can feed the same queue. The same ticket list also accepts messages from phones and social apps once you have finished connecting WhatsApp, SMS and Messenger to your ticket queue.
Inbound mail also increments the email channel counter as each message is stored. How your channel message counts are counted covers what that number includes and how to read a zero.