Email support in your unified inbox

An email backlog behaves nothing like a chat queue

Chat is synchronous. Someone opens the widget, watches for a reply, and drops off if it doesn't come. That queue is a live one, worked first in, first out, and the whole job is speed. Email is the opposite. By the time a message reaches you the sender has already closed the tab and gone back to their day. They are not sitting on the reply, and they expect an answer measured in hours, not seconds. What accumulates is a backlog, not a live line, and a backlog is worked differently. You sort it by topic and urgency, you answer the thing that matters most rather than the thing that happened to arrive first, and nobody is penalized for taking a moment over a considered reply.

That difference is the reason email is worth handling on its own terms instead of being bolted onto a chat tool. Inbound lands in the same unified inbox as your chat, SMS, and voice conversations, tagged as email, but the way your team works it is closer to triage than to a race.

The thread carries its own history

Email is the one channel that quotes itself. A reply arrives with the entire prior exchange pasted underneath it, grouped under a subject line that has followed the conversation since it started. Nothing is ephemeral the way a chat session is, because the record is inside the message.

That record is also where email gets hard. A thread that has been forwarded twice and answered by four people buries the real question in the middle: the sentence still waiting on a reply sits above a wall of quoted history, and below it sit older asks that were settled days ago. Read the message top to bottom and you can end up answering something that closed three messages back, or treating a quoted line as the live request. So before the agent can draw on your published answers, it has to work out which line in the thread is the one that still needs one. Signatures, legal disclaimers, a "Sent from my iPhone", and the chevron-quoted copies of earlier mail are all noise for that: they pad the message without moving the question, and what is worth reading is usually the few lines a person actually typed this time.

It helps your team for the same reason. When a thread reaches a person, the whole story is already in front of them. They are not rebuilding a conversation from a one-line summary; they are reading the actual back-and-forth, which is why email tends to be the most self-contained and most auditable channel you run.

Attachments change what "resolved" means

Email brings files with it. A customer attaches a screenshot of the error, the PDF invoice they are querying, a photo of the item that arrived damaged, the order confirmation they were told to keep. Some of those questions cannot be settled from the text alone, because the answer is in the file rather than the sentence. The attachment travels with the thread into the inbox, so whoever picks it up has it there to open. This is part of why email leans on a person more often than a live chat does. The routine wording is easy, but the resolution sometimes lives in a document only a human should read and act on. Attachments also fail in email-specific ways: the "please see attached" that arrives with nothing attached, the photo pasted inline into a signature block instead of sent as a file, the scan too low-resolution to make out the figure the whole question turns on. When the answer depends on a file the agent cannot safely read, that is the signal to route the thread rather than reply to it.

Draft a reply for a person to approve — or let it send

Because email is asynchronous, it is the natural home for a review step. Nobody is watching a spinner, so spending a minute on approval costs nothing in how the reply feels to the sender. Evoriqa uses that. The AI reply copilot drafts a grounded response from your knowledge and puts it in front of a teammate, who reads it, edits a line if they want to, and sends. Nothing goes out under your name until a person has approved it. Review is the default on purpose: a new email channel starts with your team in the loop, and the review step costs the least here, because the sender was never expecting an instant answer in the first place. When you are ready, you can let the agent send on its own — see below.

The draft is not the only thing the agent can do inside a thread. An emailed "where is my order" can have the order looked up and the status written back; a request that needs tracking can be turned into a ticket. Each of those runs is logged, so you can see what the agent did and which answer it gave, not just that it replied.

Or let the agent answer on its own

Review is the default, but it is not the only option. An email channel carries the same reply-mode control as your chat channels, with one difference: it starts switched off, because a misfired auto-reply costs more on email than on a live chat. Turn it on and the agent answers mail with the same grounded pipeline it uses everywhere else — a plain-text reply from the From name and subject you set — while anything that asks for a person, or that looks like another machine's auto-reply or a bounce, still lands in the inbox for a teammate. Draft for review sits in between: the agent writes every reply into the inbox for a person to approve. You choose per channel, and you can start in review and graduate to full answers once you trust the drafts.

What it settles, and what it routes

A large share of any support mailbox is the same handful of questions asked in different words: hours, policies, order status, how something works. Those are the ones the agent can answer so they never turn into tickets, clearing the volume that would otherwise bury the threads that genuinely need judgment. Everything else is routed to the right person, and because the queue is asynchronous you can route by topic and priority rather than grabbing whatever sits on top. In professional services this split is the whole value: a law firm's mailbox mixes fee and process questions the agent can settle with matters that must reach a solicitor untouched.