Threads New Features and Road Map
Threads features added since 2016 1
2016.1 Network Call Ingestion/Threads Telephony Appliance 1
2016.2 Automated Account Setup and monitoring 1
2016.3 Free Email Ingestion Account 2
2016.4 Merging of companies 2
2016.5 Merging of contacts 3
2016.6 Threads Enron Database Update (TED) 4
2017.1 File/attachment handling 4
2017.2 Optical Character Recognitions - Searching scanned documents 5
2017.3 Automatic Speech Recognition - Searching and transcribing phone calls 7
2017.4 Automatic company creation 9
2017.5 Private/shared contact channels 10
2017.6 Google speech 11
2017.7 Printable transcriptions 11
2018.1 Contextual changes to channel privacy settings 12
2018.2 Dynamic deployment of speech recognition services 13
2018.3 Threads notifications system 15
2018.4 HubSpot email integration 17
Threads features in the pipeline 18
HubSpot phone call integration 18
Import Google Contacts 18
Threads Slices - (“users and groups”) 18
Mobile Phone App 19
Intelligent Contact Identification 19
Thread Deduplication 19
Keyword analysis 20
Intelligent Message Labels 20
Contact Voice Recognition 20
Threads Contact Directory Publication 21
Threads originally ingested phone calls by means of a process we called PBX Call Ingestion that involved custom software specific to the subscriber’s telephone system (PBX). The disadvantage of PBX Call Ingestion was that different software was needed for every different phone system - of which there are many.
With Network Call Ingestion, phone call traffic is intercepted directly from the subscriber’s network and so is independent of the phone system. It is necessary to have a small low-cost computer (PC) connected to the subscriber’s network to collect the calls - we call this the Threads Telephony Appliance - and is available through a Threads channel partner.
A new web application called the Threads Manager allows new subscribers to create a Threads account, specify payment details and later view storage usage. Previously, this had to be done by JPY.
In conjunction with the automated account setup, the Threads Manager creates an email account from which Threads can ingest messages. This obviates the need for the subscriber to create an email account or to provide authentication details of existing accounts.
This allows users to combine multiple company records into a single record and hence simplify company management. In Threads, a company may have multiple physical addresses and it is much easier to have one company record for each legal entity. This is particularly useful when importing company records from legacy CRM systems.
This allow users to combine multiple contact records into a single record and hence simplify contact management. In Threads, a contact may have multiple contact channel addresses and it is simpler to have one contact record for each real person. This is particularly useful when importing contact records from legacy CRM systems.
TED is a read-only version of Threads. Updates to Threads are not implicitly incorporated into TED. This has been updated to reflect the last 2016 version of Threads.
File attachments are viewable in their own grid accessed from a button in the message view. The grid renders each file as a thumbnail which may be magnified or downloaded. The attachment grid also provides its own search and sort tools. When attachments are ingested, document text is extracted and, in the case of graphic documents, Optical Character Recognition (see 2017.2) is automatically performed to extract text where available. This text is a searchable resource.
When a scan of a printed document is attached to an email, what is sent is not a compute readable text file like from Word say, but a picture comprising millions of pixels. As such, searching the millions of digital pixels, is of no help in finding a word. What is necessary is to use machine intelligence to work out the shapes of the characters and the words they make up. We call this process Optical Character Recognition or OCR. Threads can now automatically perform OCR once the message and attachment have been ingested.Once this happens, the scanned documents can be searched just like regular email body.
The following is an example of a relatively low quality scan sent as an attachment to an email...
And here is the resulting OCR text, which can be searched. Without OCR, if a user searched for the phrase “Door & Window Shop” for example, this message would not be found.
OCR involves a significant amount of computation which may take some minutes to complete. However, since a user typically does not search for a message for days or weeks after it has been ingested, this is not generally an issue.
Previously, Threads’ users could search, sort and classify phone call from associated metadata such as participants, telephone numbers, time and duration of calls. This was extremely useful in finding calls and seeing them in the context of other messages but it did not permit users to access the content of the call, except by listening to it. Automatic Speech Recognition (ASR) analyses the acoustic waveform and endeavours to transcribe it into text, just as a human would. By so doing, the call can be searched for keywords.
Because Threads ingests calls directly from the network (see 2016.1) rather than from the phone system, it is generally able to pre-process the conversation and hence provide much better accuracy than might be achieved otherwise.
We provide two viewing options for call transcriptions. The Dialogue View shows each caller speech in a speech bubble. This makes it very easy to follow the conversation, and to scrub through a long conversation, isolating the section of interest.
The Block View segments each speaker’s text into one continuous block per speaker. Although this is difficult to follow, it is very helpful if the user wishes to cut and paste sections of a call transcription.
Just like OCR, ASR involves a significant amount of computation which may take some minutes to complete. However again like OCR, since a user typically does not search for a (phone call) message for days or weeks after it has been ingested, this is not generally an issue.
Prior to this feature, when messages were exchanged between companies not already in the Threads database, Threads created contacts without a parent company - we call these orphan contacts. However, it is often useful to thread together several messages between the same company, even if the company has not yet been identified by a user or imported from an existing address book. With automatic company creation, any message ingested involving an email channel with a domain that is not known to Threads and not generic (i.e. not gmail.com, yahoo.com, etc), will cause the automatic creation of a new company, using the domain name as the company name. For example and email from say, “email@example.com” will result in the creation of a company called “Widgets” related via the contact channel value “firstname.lastname@example.org” to a contact called “Fred”. So called orphan contacts, are now only be used for contact channels with generic domains.
Previously, messages (emails and phone calls) from unknown contacts were visible only to the addressed user. This prevented private messages from being shared. However, once the contact is linked to a known company, then their messages may become shared (depending on admin preferences). This meant that users were discouraged from entering the company details of non-work-related contacts. Private/shared contact channels allow users to selectively decide which contacts are personal, so that even if the company details are entered, specific contacts can still be identified as private.
This feature has involved a fundamental redesign of architecture for filtering messages. The previous “traffic light” filters have changed thus:
“Contacts I know” is now “Known shared Contacts”
“Contacts I might know” is now “Tentative [shared/private] Contacts”
“Contacts I don’t know” is now “Known private Contacts”
If a message is exchanged using a previously unknown (to Threads) contact channel, then Threads will create a new contact channel and automatically decide whether the contact channel should be shared or private, dependent upon some rules and admin preferences. However, because this has not involved a human decision, then the channel is marked as “tentative”, so users can immediately see whether a message involves new contact channels that need to be confirmed. Once the user has manually confirmed or changed the status of channel, then it is is no longer tentative.
It has always been a design goal to offer Threads’s subscribers to the best message processing services available. Threads subscribers can choose based on performance and price. With the introduction of automatic speech recognition (ASR) to Threads we offered the Speechmatics engine. Since then, Google has introduced its speech recognition API and we have now completed the integration into Threads. Although most subscribers will choose just one speech recognition engine, we have added the option to switch between engines to compare transcriptions (see 2017.7)
Threads uniquely displays ASR transcriptions in an html rendition of a typical SMS display format, highlighting spoken words and allowing users to scrub through transcriptions. This user interface greatly enhances the user experience and makes it very easy to locate and isolate sections of a call. We have added the ability to print transcriptions. In the screenshots below, we show the Google Speech and Speechmatics transcriptions for the same call. The print icon appears next to the “Show Speechmatics version”...
It is often necessary to change the default status of a contact channel from “private” to “shared” and vice versa (see 2017.5). Previously, this necessitated drilling into the contact record and selecting the appropriate privacy. This feature allows the user to change the privacy of a channel directly from the message list. To use this feature, first expand the with the chevron button and then hover the mouse pointer over any contact showing a tentative channel (amber blob). This will render a pop-up menu from which private or shared may be selected.
A design goal of Threads is to support as many automatic speech recognition systems as are commercially available. We have begun to roll this out with services from Speechmatics and Google Speech (2017.5).
Although most subscribers will wish to subscribe to only one service, many will wish to experiment with various services to decides which performs most cost-effectively.
To assist this, we allow users to subscribe to several services and choose among transcriptions available. Subscribers can disable services selectively from the Administrator Preferences…
Then manually apply services as required…
While users may share messages with a particular company, they may easily miss messages which are not specifically addressed to them. This often happens when a user responds to an email message from a third party but forgets to “reply all”.
The Threads notifications system provides a way of automatically alerting the user when messages have been sent to or received from a particular company.
To set up, the user opens any message exchanged with the target company. The user then clicks the “Keep and eye on Threads emails” button.
Whenever a subsequent message is exchanged with that company a red circular disk containing the number of unacknowledged messages will be appended to the user’s settings button.
If the user clicks the settings button, he/she will be able to select a list of notifications and display which companies on an “eye” is being kept.
Hubspot is cloud service providing CRM, Sales and Marketing management.
This feature uses the HubSpot API to seamlessly integrate Threads email messages into HubSpot. As such Threads will automatically include email messages into relevant “Deals”. The email messages may be hosted on any IMAP server - this includes, GoogleMail, MicroSoft 365 and, of course, AppleMail.
Hubspot is cloud service providing CRM, Sales and Marketing management. HubSpot provides no way to include phone calls in “deal” streams.
This feature will use the HubSpot API to seamlessly integrate Threads phone calls into HubSpot, If Threads speech recognition services deployed, then the HubSpot user will also get the benefit of phone call transcriptions.
Although Threads will build and manage contacts and companies based upon messages received, some subscribers will wish to pre-load Threads with existing companies and contacts. There are many different CRM and address book systems in use and currently, Threads allow imports of contact records only as comma or tab delimited text files.
To make this process easier, Threads will support the import of Google Contact lists. Google supports the conversion of many type of contact list into Google Contacts.
In larger organisations there is often a need for fine levels of privacy. This is commonly implemented through a system of “user” and “group” privileges whereby each user may belong to one or more groups and it is the “group” rather than the user that has the associated privileges. The “user and group” scheme is something appropriate to file systems generally, but not something that was designed with the non-computing user in mind. It can complicate the user interface and since in Threads, it is a contact channel rather than the message that is assigned the privacy setting, implementing such a scheme would likely make for even more user confusion.
The solution is a novel approach we call “slices” whereby users can share access to slices of messages their private messages. In view of its novelty, the full description of “slices” is currently only available under a non-disclosure agreement. Please contact us if interested.
Although there are various ways of ingesting calls from mobile phone networks, it is not always possible for the subscriber to implement them. The Threads Mobile Phone app will provide two functions:
When messages are exchanged with contacts not already in the Threads database, Threads will attempt to identify the contact by doing background research in the Threads database and on the web. This includes identifying individuals from their phone number and attempting to discover full names and job titles.
When creating email responses (ie where the user types “reply”), many email applications automatically insert the original text in the response. Hence each email response grows longer and repeats much information. In the following example, Lucy typed a message of 7 characters to Miranda, which became an email reply of 270 characters...
This can be useful to establish the context of a response but becomes very distractive when printing a thread of threads - for example “court bundle”. It also distorts correspondence statistics used for the intelligent classification of messages. When a message is deduplicated, Threads attempts to extract only new text and offers this as an optional view. The deduplicated messages can optionally be specified in searches and for keyword statistics.
This feature extracts keywords from messages and builds a database describing the “information value” of keywords in the context of users, companies and projects. In English, high frequency words such as “the” and “of” would be expected to have low information value whereas low frequency words such as “taxable” and “profit” would have a higher information value. Using this database, it becomes possible to identify unusual events, establish connections and sometimes predict future behaviour.
Threads currently provides “Projects” as a method for grouping messages relating to specific projects. Projects may be automatically created and messages automatically added to those projects using user-defined rules - for example, the message subject contains a case number.
Labels will provide a similar function except that Threads will automatically learn the rules from user behaviour. For example, when a message is delivered, users will be able to assign one or more labels to the message. These can be existing labels or newly created labels. When doing this, Threads will offer a list of existing labels in order of the messages closeness of fit, If the user decides no label is a sufficiently good fit, then a new label can be created. Once a message is manually associated to a project, Threads incorporates information from the message into the description of the label - ie it learns from it.
When calls involve connection to a company switchboard, it is not possible to identify the specific contact spoken to. Currently, Threads describes these call with “somebody” at such and such company, and it is up to the user to identify the specific contact. Contact voice recognition will learn from previous calls and offer the user the most likely contact for confirmation.
Email and phone users find it useful to draw email addresses and telephone numbers directly to their telephone or email client. This feature commonly uses a protocol called Lightweight Directory Access Protocol (LDAP). This feature enables subscriber directories to be published using LDAP. Although LDAO is supported by Threads, it is not provided as part of the service.