In our online world, a great many things are real time. When we click to open a page, we expect it to respond in a matter of seconds. When we send a chat message via Slack, we expect it to appear almost instantly. Modern APIs and web tools like webhooks mean that a change which is made in one system can be reflected in another system within moments.
Unfortunately, one important piece of technology which we all rely on is decades older than the world wide web. That technology is email, more formally known as the Simple Mail Transport Protocol (SMTP).
While more modern technology is designed to focus on speed, taking action instantaneously and giving direct feedback if it "times out", email was instead designed to be high on reliability and low on timeliness. Warnings about emails not being delivered are generally only get sent after a few hours of delivery attempts, with some email services trying to deliver emails for up to a week before "hard bouncing" (the mail system giving up).
These differences are baked into the architecture of email systems, which rely entirely on a series of queues to send and receive messages. When you first click Send, your email begins its journey through multiple queues which feed special email processes run by the server, known as daemons. These email daemons work together to handle each of the steps involved in sending an email, converting your message's text to a hexadecimal format, confirming valid recipients, and preparing the data to actually transfer, all before it ever leaves your email server. If any of these various processes encounters an immediate problem with the message, that message is re-queued in something known as a "Deferred Queue", which the server will attempt to re-process the on a decaying frequency. The result is that the server will at first attempt to re-process the message often, then continue to re-process it at increasingly long intervals, leading to delays of up to a week before the email is delivered, or you're notified that the delivery failed! At the other end of the process, the message goes through a similar process in the recipient's email server - which involves a whole other set of queues!
Most of the time, this process doesn't affect us too much - while watching a blank loading screen frustrates us as users, who have nothing to do but count the seconds, the nature of email as a non-real-time system means that we don't normally see or even realize that a message is being processed. Whether it takes 30 seconds or 30 minutes to wind its way through the half dozen or more queues to "ping" our inboxes, the process isn't as visible, and so isn't as obvious when it requires more time than normal.
There are, however, an increasing number of situations where Accelo users want to see a much more instantaneous transition between a customer sending an email - such as to [email protected] - and seeing that email appear in Accelo. When it comes to SLAs and being as responsive to your clients as possible, we wish it could be instantaneous too. Unfortunately, the nature of email - reliable, but not instantaneous - makes this impossible to guarantee.
Trying to make this process instantaneous for Accelo users is all the more difficult because Accelo is often the last step in a long line of queues. Emails are forwarded to Accelo only after the receiving mail server runs the message through its queues - receiving the message, queuing it to be processed, relaying it to the relevant user inbox(es), and then processing those inboxes' individual mail rules to queue and forward the message, finally, to Accelo's email capture system. In addition to being "the last to know", Accelo's email capture system does more than simply receive the message; that system processes the email to discern its context, intent and relationship to determine whether the email should be captured by Accelo at all, and if so, where and how it should appear. All of that, of course, requires more time than your typical email server does, which simply moves the message on to the next queue.
Because email queues can be so unpredictable, your best bet to ensure that your important client requests are received as quickly as possible to receive them via another method. In these situations, we recommend using our In-App Request, Forms API, RESTful API, Zapier integration or Client Portal. Using these tools, you can take in client requests directly via methods like a form on your website or through another application, and for your more savvy clients, via your Accelo Client Portal. Because these methods connect directly to your Accelo account, both you and your clients know that when they hit "go", that your team will receive it in Accelo directly.
Over the past two weeks, we've had two occasions where code changes caused our email processing system to back up, requiring more time to process emails than normal. When situations like these arise, we'll post the details to @AcceloStatus on Twitter. Be sure to follow us, and check us out for further details on issues like these.
To ensure that we don't encounter these sorts of delays when processing emails, our engineering team have been making improvements to the email capture system, and have been closely watching its queues as we continue to grow. While we'll always work to process emails as close to real-time as possible, because of how email functions, we recommend using another method to track communications which require notification and responses of less than thirty minutes.
