We are happy that the vast majority of customer reviews for Threads give us 5 stars. But some of the reviews rightly draw attention to the fact that the initial setup of Threads can be a pain to configure.
Well, they are right. It can be a pain. So while we cannot fix the underlying causes, which are mostly beyond our control, we are building up a great deal of knowledge of the customer experience and looking at ways we can make life easier. This blog examines some of the issues in collecting emails.
Who can read your email?
The first challenge that arises when ingesting email is that of security. Email service providers have learned how easily email servers are hacked. Most have started to put in place elaborate procedures to ensure that anyone reading an email account has the authority to do so. The standard way to do this was using the familiar username/password mechanism. However it became clear that not only was there a risk a password could be stolen, but it was relatively easy to try various passwords to see if one gave access.
The standard way to defeat this, is what is called multi-factor authentication. So, instead of relying on one device to login, you use two or more devices. Typically, when you try to log-in from a computer, a code is sent to the your mobile phone. You must then enter this code before access is permitted. The low chances of an opponent gaining simultaneous access to both devices, greatly reduces the risk of unauthorised access.
There are other methods such as bio-metric checks like fingerprints or facial scans.
These are all very effective, but produce a real problem when you want to allow access to your emails by a trusted service such as Threads or, say, a spam filter.
Although you can authorise proxy-access, it significantly complicates the logging in process in a way that is difficult to simply for the user and is a pain to configure.
Some service providers, typically the spam filtering services, get around this by obtaining “carte blanche” authority to read every bit of email in or out of a company. Although this is an approach Threads could take, we don’t. This means that the initial setup is more complicated, but once done, runs seamlessly and is far less intrusive.
Providers, providers, providers
One of Threads’ many unique features is its ability to connect to the email services of common providers. Some companies use a mixture of email services and want to be able to ingest email from all of the: MicroSoft, Apple, Google, Yahoo, and a host of others.
While Threads can do this, because each mail system has different setup rules, we try to ensure that new subscribers can connect to any of them in a unified and consistent way. This is not as easy as just supporting one service provider, but it has the major benefit that if the subscriber decides to change their email service provider or even add another, then Threads can handle it.
Protocols, protocols, protocols
In the early days, the rules (or protocols) for exchanging emails were set down in what is called an “Request For Comment (RFC)” document. By the process of open discussion, rules are finalised so that any user may exchange email with any other user who obeys those rules.
We designed Threads around these Open rules.
However, many users do not access their email from a dedicated email application – such as Microsoft Exchange, or AppleMail. Instead, they access their email from a dedicated web application, using a standard web browser. For example Internet Explorer, Safari or Chrome. Many email service providers would love the whole World to use only their email systems. This is because it would make things difficult for other systems to access their users’ email. Fortunately, they cannot make it impossible without losing all their customers, but it does provide another challenge in the setup.
Access or ingest?
Many Threads users – typically those using Hubspot – are totally unaware that Threads is ingesting their emails. Or in some cases, their telephone calls. But we developed Threads as a stand-alone message sharing system. This means some users need their messages ingested and some need to log in to see them. This means there are two separate credentials that Threads needs:
- the login credentials i.e. the rights to log into Threads); and
- the message account (email) credentials i.e. the rights Threads needs to log in to user email accounts.
This is another complication that is difficult to hide.
Push or Pull?
Quite reasonably, some subscribers do not wish to divulge their users’ email login credentials. Therefore Threads provides a mechanism called “pushed email” whereby the subscriber sets up an auxiliary email account specifically for Threads. The subscriber arranges for Threads to ingest the email and transfers it automatically to a special account. This removes the need to divulge individual account credentials.
Most subscribers, particularly those using Threads for a limited time, are happy to share these credentials. Accordingly this is the default setup. But pulling is always an option, although slightly more involved to set up.
Historic or Ongoing?
Last but not least, Threads can ingest messages from the past (we call these historic ingestion). Threads can also handle messages in the future (we call this ongoing ingestion). Subscribers may choose one or the other or, more commonly, both. Yet another thing to set up and a pain to configure.
The good news
There are other mechanisms commonly in use to protect email accounts. For example, Application-Specific Passwords. The good news is that usually only one person sets Threads up. Once completed, no further action is required. There are still things that can stop Threads ingesting, such as users that change their passwords, mail systems that “throttle back” access, or connected services that mysteriously deny Threads access. But by and large, most users experience seamless operation.
As we gain more experience of the idiosyncrasies of varios email systems we will endeavour to make things easier in the setup. We are also looking at ways of providing automatic notifications when things that are beyond our control go wrong.
We do our best to make life as easy as we can for our users, but one thing you may be absolutely sure of, Threads does things that no other system we know of can do, and despite the pain to configure, users quickly get that time back.